Context Navigation

← Previous Change
Next Change →

Changeset 39845 for trunk

Timestamp:

Dec 11, 2016, 11:56:48 AM (10 years ago)

Author:

eugene

Message:

updates to analysis and calibration

Location:

trunk/doc/release.2015

Files:

: 2 edited

ps1.analysis/analysis.tex (modified) (12 diffs)
ps1.calibration/calibration.tex (modified) (16 diffs)

Legend:

: Unmodified
: Added
: Removed

trunk/doc/release.2015/ps1.analysis/analysis.tex

-              r39839
+              r39845
 The variance image, if not supplied is constructed by default from the
 flux image using the configuration supplied values of \code{GAIN} and
 \code{READ\_NOISE} to calculate the appropriate Poisson statistics for
+\code{READ_NOISE} to calculate the appropriate Poisson statistics for
 each pixel.  In this case, the image is assumed to represent the
 readout from a single detector, with well-defined gain and read noise
 …
 image.  The background image and the background standard deviation
 image are kept in memory from which the values of \code{SKY} and
 \code{SKY\_SIGMA} are calculated for each object in the output catalog.
+\code{SKY_SIGMA} are calculated for each object in the output catalog.
 \subsection{Initial Object Detection}
 …
 the covariance, if known. At this stage, the goal is only to detect
 the brighter sources, above a user defined S/N limit (configuration
 keyword: \code{PEAKS\_NSIGMA\_LIMIT}).  A maximum of
 \code{PEAKS\_NMAX} are found at this stage.  The detection efficiency
+keyword: \code{PEAKS_NSIGMA_LIMIT}).  A maximum of
+\code{PEAKS_NMAX} are found at this stage.  The detection efficiency
 for the brighter sources is not strongly dependent on the form of this
 smoothing function.
 …
 {\em key col} for this peak (as used in topographic descriptions of a
 mountain).  If the key col for a given peak is less than
 \code{FOOTPRINT\_CULL\_NSIGMA\_DELTA} (4.0) sigmas below the peak of
+\code{FOOTPRINT_CULL_NSIGMA_DELTA} (4.0) sigmas below the peak of
 interest, the peak is considered to be {\em locally insignificant} and
 removed from the list of possible detections.  In the vicinity of a
 …
 to find a value of $\sigma_W$ for which $f$ is expected to be 0.65.
 \note{what is the expected ratio of $\sigma_x$ to the true value?}.
 We call this value the \code{MOMENTS\_GAUSS\_SIGMA}.  We use an
 aperture with a radius of \code{PSF\_MOMENTS\_RADIUS} = 4$\times$
 \code{MOMENTS\_GAUSS\_SIGMA} to select the pixels for the measurement.
 Once \code{PSF\_MOMENTS\_SIGMA} has been determined, moments are
+We call this value the \code{MOMENTS_GAUSS_SIGMA}.  We use an
+aperture with a radius of \code{PSF_MOMENTS_RADIUS} = 4$\times$
+\code{MOMENTS_GAUSS_SIGMA} to select the pixels for the measurement.
+Once \code{PSF_MOMENTS_SIGMA} has been determined, moments are
 measured as defined below.
 …
 If the measured centroid coordinates ($x_0, y_0$) differs from the
 peak coordinates be a large amount (\code{MOMENT\_RADIUS}), then the
+peak coordinates be a large amount (\code{MOMENT_RADIUS}), then the
 peak is identified as being of poor quality and is rejected.  In
 both of these cases, it is likely that the `peak' was identified in a
 …
 limited at the low and high ends by $R_{\rm min} < M_r < R_{\rm max}$
 where $R_{\rm min}$ is the first radial moment of the PSF stars, or
 .75$\times$ \code{MOMENTS\_GAUSS\_SIGMA} if that cannot be
 determined.  $R_{\rm max}$ is set to \code{PSF\_MOMENTS\_RADIUS}, the
+.75$\times$ \code{MOMENTS_GAUSS_SIGMA} if that cannot be
+determined.  $R_{\rm max}$ is set to \code{PSF_MOMENTS_RADIUS}, the
 size of the moments aperture.
 …
 registered as part of the model function code.  Another function is
 then used to return the appropriate function for a specific model
 type.  For example, the \code{psModelLookup\_GetFunction} will return
+type.  For example, the \code{psModelLookup_GetFunction} will return
 the \code{psModelLookup} function for a given model type.  This
 mechanism makes it very easy to add new model functions into the
 …
 their peaks, as well as an approximate signal-to-noise ratio.  All
 objects with a S/N ratio greater than a user-defined parameter
 (\code{PSF\_SHAPE\_NSIGMA} ???) are selected by PSPhot, though objects
+(\code{PSF_SHAPE_NSIGMA} ???) are selected by PSPhot, though objects
 which have more than a certain number of saturated pixels are excluded
 at this stage.  PSPhot then examines the 2-D plane of $\sigma_x,
 …
 PSPhot will use the user-selected galaxy model to attempt the galaxy
 model fits.  In the configuration system, the keyword \code{GAL\_MODEL}
+model fits.  In the configuration system, the keyword \code{GAL_MODEL}
 is set to the model of interest.  All suspected extended objects are
 fitted with the model, allowing all of the parameters to float.  The
 …
 value for the ApResid scatter is then used by PSPhot as the best PSF
 model for this image.  The number of models to be tested is specified
 by the configuration keyword \code{PSF\_MODEL\_N}.  The configuration
 variables \code{PSF\_MODEL\_0}, \code{PSF\_MODEL\_1}, through
 \code{PSF\_MODEL\_N - 1} specify the names of the models which should be
+by the configuration keyword \code{PSF_MODEL_N}.  The configuration
+variables \code{PSF_MODEL_0}, \code{PSF_MODEL_1}, through
+\code{PSF_MODEL_N - 1} specify the names of the models which should be
 tested.
 …
 The surface brightness values are sampled at a number of radial
+annuli, with the radii defined in the configuration ({\tt
+  RADIAL.ANNULAR.BINS.LOWER \& RADIAL.ANNULAR.BINS.UPPER}).  For each
+source, the resulting surface brightness profile is saved in the
+output cmf-file as an N-element value in the FITS table ({\tt
+  PROF\_SB}).  The flux at each radial position and the fill-factor
+(fraction of pixels used to the total possible) as also saved as
+equal-length vectors in the FITS table ({\tt PROF\_FLUX and
+  PROF\_FILL}).  The values of the radial bins are saved in the cmf
+header ({\tt RMIN\_NN, RMAX\_NN}).
+annuli, with the radii defined in the configuration
+(\code{RADIAL.ANNULAR.BINS.LOWER} \&
+\code{RADIAL.ANNULAR.BINS.UPPER}).  For each source, the resulting
+surface brightness profile is saved in the output cmf-file as an
+N-element value in the FITS table (\code{PROF_SB}).  The flux at each
+radial position and the fill-factor (fraction of pixels used to the
+total possible) as also saved as equal-length vectors in the FITS
+table (\code{PROF_FLUX} and \code{PROF_FILL}).  The values of the
+radial bins are saved in the cmf header (\code{RMIN_NN},
+\code{RMAX_NN}).
 \note{these profiles are not saved in PSPS}

trunk/doc/release.2015/ps1.calibration/calibration.tex

-              r39840
+              r39845
 % Pick a terse version of the title here;
 \shorttitle{Pixel Analysis in PS1}
+\shorttitle{PS1 Calibration}
 \shortauthors{E.A. Magnier et al}
 \begin{document}
 \title{Pan-STARRS Pixel Analysis : Source Detection \& Characterization}
+\title{Pan-STARRS Photometric and Astrometric Calibration}
 % this is a crude trick to get the order of affiliations right.  These
 …
 images.
+\section{Astrometric Model in PSASTRO}
+\code{pasastro} loads the coordinates and calibrated magnitudes of
+stars from the reference database.  A model for the positions of the
+chips in the focal plane is used to determine the expected
+astrometry for each chip based on the boresite coordinates and
+position angle reported by the header.  Reference stars are selected
+from the full field of view of the GPC1 camera, padded by an
+additional \note{25\%} to ensure a match can be determined even in the
+presence of substantial errors in the boresite coordinates.  It is
+important to choose an appropriate set of reference stars: if too few
+are selected, the chance of finding a match between the reference and
+observed stars is diminished.  In addition, since stars are loaded in
+brightness order, a selection which is too small is likely to contain
+only stars which are saturated in the GPC1 images.  On the other hand,
+if too many reference stars are chosen, there is a higher chance of a
+false-positive match, especially as many of the reference stars may
+not be detected in the GPC1 image.  The seletion of the reference
+stars includes a limit on the brightest and fainted magnitude of the
+stars selected.
+\section{Astrometric Models}
 Three somewhat distinct astrometric models are employed within the IPP
 …
 \begin{eqnarray}
   L & = & C^L_{0,0} + C^L_{1,0} X_{\rm chip} + C^L_{0,1} Y_{\rm chip} + \delta L(X_{\rm chip}, Y_{\rm chip}) \\
   M & = & C^M_{0,0} + C^M_{1,0} X_{\rm chip} + C^M_{0,1} Y_{\rm chip} + \delta M(X_{\rm chip}, Y_{\rm chip}) \\
+  M & = & C^M_{0,0} + C^M_{1,0} X_{\rm chip} + C^M_{0,1} Y_{\rm chip} + \delta M(X_{\rm chip}, Y_{\rm chip})
 \end{eqnarray}
 …
   Q & = & \sum_{i,j} C^Q_{i,j} (X_{\rm chip} - X_0)^i (Y_{\rm chip} - Y_0)^j
 \end{eqnarray}
+\note{need to discuss the WCS keywords, both standard and
   non-standard, used to represent these polynomial transformations}
+\note{need to complete this discussion of the WCS keywords, both
+  standard and non-standard, used to represent these polynomial
+  transformations}
 \begin{verbatim}
+CTYPE1,2 : RA---WRP, DEC--WRP & RA---DIS, DEC--DIS (ill-defined since the WRP entries do not generate RA,DEC)
+Here is a table of the keywords and the related terms from Eqns above:
+CTYPE1,2 : RA---WRP, DEC--WRP & RA---DIS, DEC--DIS
 CRVAL1,2 : C^{L,M}_{0,0}
 CRPIX1,2 : X_0, Y_0
 …
 and photometric data from the reference database.
+\subsection{Reference Catalogs}
 During the course of the PS1SC Survey, several reference databases
 have been used.  For the first 20 months of the survey, \code{psastro}
 …
 catalog.  \note{discuss history of the different refcats?}
+Coordinates and calibrated magnitudes of stars from the reference
+database are loaded by \code{pasastro}.  A model for the positions of
+the 60 chips in the focal plane is used to determine the expected
+astrometry for each chip based on the boresite coordinates and
+position angle reported by the header.  Reference stars are selected
+from the full field of view of the GPC1 camera, padded by an
+additional \note{25\%} to ensure a match can be determined even in the
+presence of substantial errors in the boresite coordinates.  It is
+important to choose an appropriate set of reference stars: if too few
+are selected, the chance of finding a match between the reference and
+observed stars is diminished.  In addition, since stars are loaded in
+brightness order, a selection which is too small is likely to contain
+only stars which are saturated in the GPC1 images.  On the other hand,
+if too many reference stars are chosen, there is a higher chance of a
+false-positive match, especially as many of the reference stars may
+not be detected in the GPC1 image.  The seletion of the reference
+stars includes a limit on the brightest and fainted magnitude of the
+stars selected.
 The astrometric analysis is necessarily performed first; after the
 astrometry is determined, an automatic byproduct is a reliable match
 …
   chip}, Y^{\rm ref}_{\rm chip}$ values for the reference catalog
 stars.  For all possible pairs between the two lists, the values of
 \[
 \Delta X = X^{\rm ref}_{\rm chip} - X^{\rm obs}_{\rm chip}\\
 \Delta Y = Y^{\rm ref}_{\rm chip} - Y^{\rm obs}_{\rm chip}
 \]
+\begin{eqnarray}
+\Delta X & = & X^{\rm ref}_{\rm chip} - X^{\rm obs}_{\rm chip}\\
+\Delta Y & = & Y^{\rm ref}_{\rm chip} - Y^{\rm obs}_{\rm chip}
+\end{eqnarray}
 are generated.  The collection of $\Delta X, \Delta Y$ values are
 collected in a 2D histogram with sampling of \note{XXX} pixels and the
 …
 astrometry guess for the chip.
+\note{option to downweight based on photometric inconsistency : not
+  used in PS1 analysis}
 \subsection{Chip Polynomial Fits}
 …
 ($C^{L,M}_{0,0}$) and those which define the offset from focal plane
 to tangent plane ($C^{P,Q}_{0,0}$).  We limit ($C^{P,Q}_{0,0}$) to be
+,0 to remove this degeneracy.  \note{disucss the measurement of the
+  camera distortion via the gradient}
+,0 to remove this degeneracy.
+The initial fit of the astrometry for each chip follows the distortion
+introduced by the camera: the apparent plate scale for each chip is
+the combination of the plate scale at the optical axis of the camera,
+modified by the local average distortion.  To isolate the effect of
+distortion, we choose a single common plate scale for the set of chips
+and re-define the chip $\rightarrow$ sky calibrations as a set of chip
+$\rightarrow$ focal plane transformation using that common pixel
+scale.  We can now compare the observed focal plane coordinates,
+derived from the chip coordinates, and the tangent plane coordiantes,
+derived from the projection of the reference coordinates.  One caveat
+is that the chip reference coordinates are also degenerate with the
+fitted distortion.  In order to avoid being sensitive to the exact
+positions of the chips at this stage, we measure the local gradient
+between the focal plane and tangent plane coordinate systems.  We then
+fit the gradient with a polynomial of order 1 less than the polynomial
+desired for the distortion fit.  The coefficients of the gradient fit
+are then used to determine the coefficients for the polynomials
+representing the distortion.  \note{write out the math of the gradients}
 Once the common distortion coming from the optics and atmosphere have
 …
 each iteration, the reference stars and detected objects are matched
 using the current best set of transformations.  These fits start with
+low order (1) and large matching radius (\note{XX}) and reduced the
+radius while allowing the order to increaes, up to 3rd order for the
+final iterations.  \note{quality of the fits as a result of this stage}.
+\note{describe the output smf file?}
+\note{discuss the real-time photometric calibration}
+low order (1) and large matching radius (\note{XX}).  As the
+iterations proceed, the radius is reduced and the order is allowed to
+increaes, up to 3rd order for the final iterations.  \note{quality of
+  the fits as a result of this stage}.
+\subsection{Real-time Photometric Calibration}
+After the astrometric calibration has finished, the photometric
+calibration is performed by \code{psastro}.  When the reference stars
+are loaded, the apparent magnitude in the filter of interest is also
+loaded.   Stars for which the reference magnitude is brighter than
+(\grizy) = (19, 19, 18.5, 18.5, 17.5) are used to determine the zero
+points by comparison with the instrumental magnitudes.  For the PV3
+analysis, the robust median \note{defined where?} is used to measure
+the zero point. For early versions of the analysis, when the reference
+catalog used synthetic magnitudes, it was necessary to search for the
+blue edge of the distribution: the synthetic magnitude poorly
+predicted the magnitudes of stars in the presence of significant
+extinction or for the very red stars, making the blue edge somewhat
+more reliable.  Note that we do not include an airmass correction in
+this zero point analysis: the airmass correction is folded into the
+observed zero point.  The zero point may be measured separately for
+each chip or as a single value for the entire exposure; the latter
+option was used for the PV3 analysis.
+\subsection{Real-time outputs}
+The calibrations determined by \code{psastro} as saved as part of the
+header information in the output FITS tables.  A single
+multi-extension FITS table is written using the \code{smf} format.  In
+these files, the measurements from each chip are written as a separate
+FITS table.  A second FITS extension for each chip is used to store
+the header information from the original chip image.  The original
+chip header is modified so that the extension corresponds to an image
+with no pixels data: \code{NAXIS} is set to 0, even though
+\code{NAXIS1} and \code{NAXIS2} are retained with the original
+dimensions of the chip.  A pixel-less primary header unit (PHU) is
+generated with a summary of some of the important and common
+chip-level keywords (e.g., \code{DATE-OBS}).  The astrometric
+transformation information for each chip is saved in the corresponding
+header using standard (and some non-standard) WCS keywords.
+\note{combine this discussion with the above?}.  For the two-level
+astrometric model, the PHU header carries the astrometric
+transformation related to the projection and the camera-wide
+distortions.  Photometric calibrations are written as a set of
+keywords to individual chip headers, and if the calibration is
+performed at the exposure-level, to the PHU.  The photometry
+calibration keywords are:
+\begin{itemize}
+\item \code{ZPT_REF} : the nominal zero point for this filter
+\item \code{ZPT_OBS} : the measured zero point for this chip /
+  exposure
+\item \code{ZPT_ERR} : the measured error on \code{ZPT_OBS}
+\item \code{ZPT_NREF} : the number of stars used to measure \code{ZPT_OBS}
+\item \code{ZPT_MIN} : minimum reference magnitude included in analysis
+\item \code{ZPT_MAX} : maximum reference magnitude included in analysis
+\end{itemize}
+The keyword \code{ZPT_OBS} is used to set the initial zero point when
+the data from the exposure are loaded into the DVO database.
 \section{DVO Description}
 The Pan-STARRS IPP uses an internal database system, distinct from the
 publically visitble database system, to determine the association
+publically visible database system, to determine the association
 between multiple detections of the same astronomical object and as
 part of the astrometric and photometric calibration process.  This
 …
 this databasing system have been somewhat expanded for the Pan-STARRS
 context.
-DVO includes two major classes of database tables: those containing
-information directly about astronomical objects in the sky and those
-containing other supporting information.  As discussed in detail
-below, the object-related tables are partitioned on the basis of
-position in the sky: objects within a region bounded by lines of
-constant RA,DEC are contained in a specific file.  The boundaries and
-the associated partition names are stored in one of the supporting
-tables.
 One of the main purposes of the DVO system is to define the
 …
 detection is associated with the closest object.
+Detections in DVO have a special piece of metadata called the
+\code{photcode} which identifies the source of the measurement.  A
+\code{photcode} has a name which in general consists of the name of
+the camera or telescope (e.g., GPC1 or 2MASS), the name (or short-hand
+name) of the filter used for the measurement (e.g., $g$), and an
+identifier for the detector, if not unique (e.g., XY01 for GPC1).
+Along with each name, there is a numerical value for the photcode.  A
+table within the DVO system, \code{Photcode}, lists the photcoes and
+defines a number of additional pieces of information for each
+photcode.  These include the nominal zero point and airmass slope, as
+well as color trends to transform a measurement in the specific
+photcode to a common system.  There are 3 classes of photcodes defined
+within the DVO system.  Those photcodes associated with detections
+from an image loaded into the database system are called \code{DEP}
+photcodes.  There are also photcodes associated with the average
+photometry values, called SEC photcodes.  There are also those
+measurements which come from external data sources for which DVO does
+not have any information to determine a calibration (e.g.,
+instrumental magnitudes and detector coordinates).  These are
+measurements are reference values and are assigned REF photcodes.
 In the implementation of DVO used for the PV3 calibration analysis,
 the database tables are stored on disk using binary FITS tables.  Each
 type of database table is stored as a separate file, or a collection
 of files if the table is spatially partitioned.  The binary FITS
+of files for table which are spatially partitioned.  The binary FITS
 tables may be optionally compressed using the (to date) experimental
 FITS binary table compression strategy outlined by REF.  In this
 …
 \code{GZIP_1}, integers use \code{RICE}.
+\subsubsection{Sky Partition}
+DVO includes two major classes of database tables: those containing
+information directly about astronomical objects in the sky and those
+containing other supporting information.  The object-related tables
+are partitioned on the basis of position in the sky: objects within a
+region bounded by lines of constant RA,DEC are contained in a specific
+file.  The boundaries and the associated partition names are stored in
+one of the supporting tables, \code{SkyTable}.  This table contains
+the definitions of the boundaries for each sky region (\code{R_MIN},
+\code{R_MAX}, \code{D_MIN}, \code{D_MAX}), the name of the sky region,
+an ID (\code{INDEX}, equal to the sequence number of the region in the
+table), and index entries to enable navigation within the table.  The
+regions are defined in a hierarchical sense, with a series of levels
+each containing a finer mesh of regions covering the sky.
+In the default used by the PV3 DVO, the partitioning scheme is based
+on the one used by the Hubble Space Telescope Guide Star Catalog
+files.  Level 0 is a single region covering the full sky.  Level 1
+divides the sky in Declination into bands 7.5\degree\ high.  Level 2
+subdivides these Declination bands in the RA direction, with spacing
+related to the stellar density.  Level 3 divides these RA chunks into
+- 8 smaller partitions.  This level exactly matches the HST GSC
+layout, and uses the same naming convention to identify the
+partitions: n0000/0000, etc. \note{more on the names?}.  Level 4
+further divides these regions by a factor of 16.  In the
+\code{SkyTable}, a region at one level has a pointer to its parent
+region (the one which contains it) and a sequence pointing to its
+children (regions it contains).  The \code{SkyTable} enables fast
+lookups of the on-disk partitions which map to a specific coordinate
+on the sky.  In general, a single DVO will have the full sky
+represented with tables at a single level, though it is possible for
+mixed levels to be used, this mode is not well tested.  For the PV3
+master database, the partitioning at the 5th level results in \approx
+,000 regions to cover the full sky, of which \approx 110,000 are
+used for the PV3 $3\pi$ data.  The densest portions of the bulge
+contain at most \approx 300k astronomical objects in the database
+files, with an associated maximum of 30M measurements in these files.
+With the compression scheme described above, this makes the largest
+database files \approx 3GB, which can be loaded into memory in 30
+seconds on our partition machines.
+The DVO software system allows the tables which are partitioned across
+the sky to also be distributed across multiple computers, which we
+call partition hosts.  A single file defines the names of these
+partition hosts and the location of the database partition on the
+disks of that machine.  The \code{SkyTable} contains elements to
+define by ID the parition host to which a partitioned set of tables
+has been assigned.  Operations which query the database, or perform
+other operations on the database, are aware of the partitioning scheme
+and will launch their operations as remote processes on the machines
+which contain the data they need.  For example, a query for data from
+a small region will launch sub-query operations on the machines which
+contain the data overlapping the region of interest.  These remote
+query operations will select the database information which matches
+the query request (i.e., applying restrictions as defined) and return
+to the master process the results.  The results from the various
+partition hosts are then merged into a single result by the master
+process.  This parallelization is critical to querying and
+manipulating the enormous database on a reasonable timescale.
 \subsection{Tables which describe objects}
 …
 in our analysis of the astrometry (see Section~\ref{sec:astrometry}).
-\subsubsection{Sky Partition}
-\note{SkyTable}
 \subsection{Other Tables}
+\note{Image Table}
+\note{Photcode Table}
+\note{FlatCorrection}
+\note{AstromOffsets}
+Data from GPC1 (and other cameras processed by the IPP) are loaded
+into DVO in units \code{smf} files generated by the Camera calibration
+stage.  As described above, these files contain all measurements from
+a complete exposure, with measurements from each chip grouped into
+separate FITS tables.  When these measurements are loaded into the
+\code{Measure} and similar tables, a subset of the information from
+the chip header is used to populated a row in the DVO \code{Image}
+table.  This table contains one row for each chip known to DVO, with
+information such as the filter (\code{photcode}), the exposure time,
+the airmass, the astrometric calibration terms, the photometric
+zero point, etc.  For GPC1 and other mosaic cameras, an additional row
+is defined to carry the projection and camera distortion elements of
+the astrometry model.  As chips are loaded into this table, they are
+assigned an internal ID (a running sequence in the table).  Images may
+also be assigned an external ID: in the case of the GPC1 images, this
+ID is defined by the processing mysql database and is guaranteed to be
+unique within the processing system.
+Other tables are used to track information used by the calibration
+system.  This includes the complete set of flat-field corrections
+determined by the photometry calibration analysis (see
+Section~\ref{sec:relphot}) and the astrometric flat-field corrections
+determined by the astrometry calibration analysis (see Section~\ref{sec:relastro})
 \section{Photometry Calibration}
 \subsection{Ubercal Analysis}
+\begin{verbatim}
+* data loaded into LSD database (Juric REF) @ CFA (?).
+* refer to Ubercal paper
+* modifications for PV3 : 2x2 grid, no new flats
+* result is a collection of zero points for photometric images
+  * discuss stats on the zero points and the airmass terms
+* does eddie still use per exposure or per star airmass terms?
+\end{verbatim}
+\note{clean up and re-word the pieces below}
+The photometric calibration of the DVO database starts with the
+``ubercal'' analysis technique as described by \cite{PS1.ubercal}.
+This analysis is performed by the group at Harvard, loading data from
+the \code{smf} files into their instance of the Large Scale Database
+(LSD, Juric REF), a system similar to DVO used to manage the
+detections and determine the calibrations.
+Photometric nights are selected and all other exposures are ignored.
+Each night \note{shorter time?} is allowed to have a single fitted
+zero point and a single fitted value for the airmass extinction
+coefficient per filter.  The zero points and extinction terms are
+determined as a least squares minimization process using the repeated
+measurements of the same stars from different nights to tie nights
+together.  Flat-field corrections are also determined as part of the
+minimization process.  In the original (PV1) ubercal analysis,
+\cite{PS1.ubercal} determined flat-field corrections for $2\times 2$
+sub-regions of each chip in the camera and four distinct time periods
+(``seasons'').  Later analysis (PV2) used an $8\times8$ grid of
+flat-field corrections to good effect.
+The ubercal analysis was re-run for PV3 by the Harvard group.  For the
+PV3 analysis, under the pressure of time to complete the analysis, we
+chose to use only a $2\times 2$ grid per chip as part of the ubercal
+fit and to leave higher frequency structures to the later analysis.  A
+th flat-field season consisting of nearly the last 2 years of data
+was also included for PV3.  In retrospect, as we show below, the data
+from the latter part of the survey would probably benefit from
+additional flat-field seasons.  \note{something for PV4}.
+By excluding non-photometric data and only fitting 2 parameters for
+each night, the Ubercal solution is robust and rigid.  It is not
+subject to unexpected drift or sensitivity of the solution to the
+vagaries of the data set.  The Ubercal analysis is also especially
+aided by the inclusion of multiple Medium Deep field observations
+every night, helping to tie down overall variations of the system
+throughput and acting as internal standard star fields.  The resulting
+photometric system is shown by \cite{PS1.ubercal} to have reliability
+across the survey region at the level of (8.0, 7.0, 9.0, 10.7, 12.4)
+millimags in (\grizy).  As we discuss below, this conclusion is
+reinforced by our external comparison.  \note{do I have a measurement
+  of the bright end stability in PV3?  basically, what is the scatter
+  per star as a function of position in the camera and magnitude?}
+The overall zero point for each filter is not naturally determined by
+the Ubercal analysis; an external constraint on the overall
+photometric system is required for each filter.  \cite{PS1.ubercal}
+used photometry of the MD09 Medium Deep field to match the photometry
+measured by \cite{JTphoto} on the reference photometric night of MJD
+(UT 02 July 2011).  \note{Scolnic et al REF} have re-examined
+the photometry of Calspec standards as observed by PS1.  They reject 2
+of the \note{XX} stars used by \cite{JTphoto} and add photometry of
+\note{XX} additional stars.  The calspec spectrophotometry values have
+also been re-examined by XX; using these new measurements, Scolnic et
+al determine new zero points for the PS1 system, which we have applied
+(see below).
 \subsection{Applying the Ubercal Zero Points : Setphot}
 …
 the bright end.  \note{recommendation}
+\subsection{Calculation of Object Photometry}
+\subsubsection{Iteratively Reweighted Least Squares Fitting (1D)}
+\subsubsection{Seletion of Measurements}
+\subsubsection{Stack Photometry}
+\subsubsection{Warp Photometry}
 \section{PV3 DVO Master Database}
 …
 \note{Figures showing the Gaia residuals}
+\subsection{Calculation of Object Astrometry}
+\subsubsection{Iteratively Reweighted Least Squares Fitting}
+\subsubsection{Seletion of Measurements}
 \section{Discussion}

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 39845 for trunk

Legend:

trunk/doc/release.2015/ps1.analysis/analysis.tex

trunk/doc/release.2015/ps1.calibration/calibration.tex

Download in other formats: