IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Changeset 39837


Ignore:
Timestamp:
Dec 6, 2016, 12:00:28 PM (10 years ago)
Author:
eugene
Message:

updates to calibration paper

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/doc/release.2015/ps1.calibration/calibration.tex

    r39836 r39837  
    277277transformation may be written as:
    278278\begin{eqnarray}
    279 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}) \\
    280 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}) \\
     279  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}) \\
     280  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}) \\
    281281\end{eqnarray}
    282282
     
    286286simply polynomials above into an alternate form:
    287287\begin{eqnarray}
    288 P & = & \sum_{i,j} C^P_{i,j} (X_{\rm chip} - X_0)^i (Y_{\rm chip} - Y_0)^j \\
    289 Q & = & \sum_{i,j} C^Q_{i,j} (X_{\rm chip} - X_0)^i (Y_{\rm chip} - Y_0)^j
     288  P & = & \sum_{i,j} C^P_{i,j} (X_{\rm chip} - X_0)^i (Y_{\rm chip} - Y_0)^j \\
     289  Q & = & \sum_{i,j} C^Q_{i,j} (X_{\rm chip} - X_0)^i (Y_{\rm chip} - Y_0)^j
    290290\end{eqnarray}
    291291
     
    427427\section{DVO Description}
    428428
     429The Pan-STARRS IPP uses an internal database system, distinct from the
     430publically visitble database system, to determine the association
     431between multiple detections of the same astronomical object and as
     432part of the astrometric and photometric calibration process.  This
     433database system, called the ``Desktop Virtual Observatory'' (DVO) was
     434developed originally for the LONEOS project, and used as part of the
     435CFHT Elixir system (Magnier \& Cuillandre REF).  The capabilities of
     436this databasing system have been somewhat expanded for the Pan-STARRS
     437context. 
     438
     439DVO includes two major classes of database tables: those containing
     440information directly about astronomical objects in the sky and those
     441containing other supporting information.  As discussed in detail
     442below, the object-related tables are partitioned on the basis of
     443position in the sky: objects within a region bounded by lines of
     444constant RA,DEC are contained in a specific file.  The boundaries and
     445the associated partition names are stored in one of the supporting
     446tables.
     447
     448One of the main purposes of the DVO system is to define the
     449relationship between individual detections of an astronomical object
     450and the definition of that object.  Before describing the database
     451schema, we will discuss the process by which detections are associated
     452with objects.  New detections are generally added to the database in a
     453group associated with, for example, an image from the GPC1 camera.  As
     454new detections are loaded, they are compared to the objects already
     455stored in the database.  If an object is already found in the database
     456within the match radius, the new detection is associated to that
     457object. If more than one object exists within the database, the
     458detection is associated with the closest object. 
     459
     460* Object-related tables
     461
     462* Other tables
     463
     464* Table storag
     465
    429466\section{Photometry Calibration}
    430467
     
    439476\end{verbatim}
    440477
    441 \subsection{Relphot Analysis}
     478\subsection{Applying the Ubercal Zero Points : Setphot}
    442479
    443480The ubercal analysis above results in a table of zero points for all
     
    450487The ubercal zero points and the flat-field correction data are loaded
    451488into the PV3 DVO database using the program \code{setphot}.  This
    452 program converts the reported zero point and flat field values to the DVO internal representation
    453 in which the zero point of each image is split into three main
    454 components:
     489program converts the reported zero point and flat field values to the
     490DVO internal representation in which the zero point of each image is
     491split into three main components:
    455492\[
    456493zp_{\rm total} = zp_{\rm nominal} + M_{cal} + K_{rm \lambda}(sec \zeta - 1)
    457494\]
    458 where $zp_{\rm nominal}$ is a static value for each filter, $K_{rm
    459   \lambda}$ is the static slope of the trend with respect to the
    460 airmass trend ($\zeta$) for each filter, $M_{cal}$ is the offset
    461 needed by each exposure to match the ubercal value, or to bring the
    462 given image into agreement with the rest of the exposures, as
    463 discussed below.  The flat-field information is encoded in a table of
    464 flat-field offsets as a function of time, filter, and camera position.
    465 
    466 \note{measurement values are modified $M_{cal}, M_{flat}$, flags}
    467 
    468 When the ubercal values are ingested into the database,
    469 
    470 \begin{verbatim}
    471 * ingest the ubercal zero points (setphot)
    472 * first pass to determine initial zero points for the full set of exposurse
    473 * measure the camera-static average correction (high-resolution flat-field residual)
    474   * report the pixel scale
    475   * discuss the structures
    476 * second pass to determine final zero points and average photometry
    477   * discuss in detail the averaging, clipping strategy, IRLS
    478 \end{verbatim}
     495where $zp_{\rm nominal}$ and $K_{rm \lambda}$ are static values for
     496each filter representing respectively the nominal zero point and the
     497slope of the trend with respect to the airmass ($\zeta$) for each
     498filter.  \note{the image zero point does not incorporate the airmass,
     499  only the measurement zero point}.  These static values are listed in
     500Table~\ref{tab:zpts}.  When \code{setphot} was run, these static zero
     501points have been adjusted by the calspec offsets listed in
     502Table~\ref{tab:zpts} based on the analysis of CALSPEC standards by
     503Scolnic et al REF.  These offsets bring the photometric system defined
     504by the ubercal analysis into alignment with the Scolnic analysis of
     505the PS1 observations of XXX calspec standard stars.  The value
     506$M_{cal}$ is the offset needed by each exposure to match the ubercal
     507value, or to bring the non-ubercal exposures into agreement with the
     508rest of the exposures, as discussed below.  The flat-field information
     509is encoded in a table of flat-field offsets as a function of time,
     510filter, and camera position.  Each image which is part of the ubercal
     511subset is marked with a bit in the field \code{Image.flags}:
     512\code{ID_IMAGE_PHOTOM_UBERCAL = 0x00000200}
     513
     514When \code{setphot} applies the ubercal information to the image
     515tables, it also updates the individual measurements associated with
     516those images.  In the DVO database schema, the normalized instrumental
     517magnitude, $M_{\rm inst} = -2.5log_{10} (DN / sec) + 25.0$ are stored
     518for each measurement.  The value of 25.0 is an arbitrary (but fixed)
     519constant offset to place the instrumental magnitudes into
     520approximately the correct range.  Associated with each measurement are
     521two correction magnitudes: $M_{\rm cal}$ and $M_{\rm flat}$, along
     522with the airmass for the measurement, calculated using the altitude of
     523the individual detection as determined from the Right Ascension,
     524Declination, the observatory latitude, and the sidereal time.
     525\note{give formula for completeness?}.  For a camera with the field of
     526view of the PS1 GPC1, the airmass may vary significantly within the
     527field of view, especially at low elevations.  In the worst cases, at
     528the celestial pole, the airmass range within a single exposure is XXX
     529- XXX.  The complete calibrated (`relative') magnitude is determined
     530from the stored database values as:
     531\[
     532M_{\rm rel} = M_{\rm inst} - 25.0 + zp_{\rm ref} + M_{\rm cal} + M_{\rm flat} + K_\lambda (sec \zeta - 1).
     533\]
     534The calibration offsets, $M_{\rm cal}$ and $M_{\rm flat}$, represent
     535the per-exposure zero point correction and the slowly-changing
     536flat-field correction respectively.  These two values are split so the
     537flat-field corrections may be determined and applied independently
     538from the time-resolved zero point variations.  Note that the above
     539corrections are applied to each of the types of measurements stored in
     540the database, PSF, Aperture, Kron.  The calibration math remains the
     541same regardless of the kind of magnitude being measured.  Also note
     542that for the moment, this discussion should only be considered as
     543relevant to the chip measurements.  Below we discuss the implications
     544for the stack and warp measurements.
     545
     546When the ubercal zero points and flat-field data are loaded,
     547\code{setphot} updates the $M_{\rm cal}$ values for all measurements
     548which have been derived from the ubercal images.  These measurements
     549are also marked in the field \code{Measure.dbFlags} with the bit
     550\code{ID_MEAS_PHOTOM_UBERCAL = 0x00008000}.  At this stage,
     551\code{setphot} also updates the values of $M_{\rm flat}$ for all GPC1
     552measurements in the appropriate filters.
     553
     554\subsection{Relphot Analysis}
     555
     556Relative photometry is used to determine the zero points of the
     557exposures which were not included in the ubercal analysis \note{how
     558  many?}.  The relative photometry analysis has been desribed in the
     559past in Magnier et al 2013 REF.  We review that analysis here, along
     560with specific updates for PV3. 
     561
     562As described above, the instrumental magnitude and the calibrated magnitude
     563are related by arithmetic magnitude offsets which account for effects
     564such as the instrumental variations and atmospheric attenuation. 
     565\[
     566M_{rel} & = & m_{inst} + ZP + M_{cal} \\
     567\]
     568
     569From the collection of measurements, we can generate an average
     570magnitude for a single star (or other object):
     571\[ M_{ave} = \frac{\sum_i M_{rel,i} w_i}{\sum_i w_i} \]
     572We find that the color difference of the different chips can be
     573ignored \note{level of this effect?}, and set the value of $A$ to 0.0.
     574Note that we only use a single mean airmass extinction term for all
     575exposures -- the difference between the mean and the specific value
     576for a given night is taken up as an additional element of the
     577atmospheric attenuation.
     578
     579We write a global $\chi^2$ equation which we attempt to minimize by
     580finding the best mean magnitudes for all objects and the best
     581$M_{\rm cal}$ offset for each exposure:
     582\[ \chi^2 = \sum_{i,j} (m_{inst}[i,j] + ZP + K \zeta + M_{clouds}[i] - M_{ave}[j]) w_{i,j} / \sum_{i,j} w_{i,j} \]
     583
     584If everything were fitted at once and allowed to float, this system of
     585equations would have $N_{exposures} + N_{stars} \sim 2 \times 10^5 + N
     586\times 10^9$ unknowns.  We solve the system of equations by iteration,
     587solving first for the best set of mean magnitudes in the assumption of
     588zero clouds, then solving for the clouds implied by the differences
     589from these mean magnitudes.  Even with 1-2 magnitudes of extinction,
     590the offsets converge to the milli-magnitude level within 8 iterations.
     591
     592Only brighter, high quality measurements are used in the relative
     593photometry analysis of the exposure zero points.  We use only the
     594brighter objects \note{mag limit}, limiting the density to a maximum
     595of \note{actual max density?} 2500 or 3000 objects per square degree
     596(lower in areas where we have more observations).  When limiting the
     597density, we prefer objects which are brighter (but not saturated), and
     598those with the most measurements (to ensure better coverage over the
     599available images).
     600
     601There are a few classes of outliers which we need to be careful to
     602detect and avoid.  First, any single measurement may be deviant for a
     603number of reasons (e.g., it lands in a bad region of the detector,
     604contamination by a diffraction spike or other optical artifact, etc).
     605We attempt to exclude these poor measurements in advance by rejecting
     606measurements which the photometric analysis has flagged the result as
     607suspcious.  \note{bad and poor psphot bits?}  We reject detections
     608which are excessively masked ({\tt PSF\_QF} $<$ 0.85, see Magnier et
     609al PSPHOT REF); these include detections which are too close to other
     610bright objects, diffraction spikes, ghost images, or the detector
     611edges.  However, these rejections do not catch all cases of bad
     612measurements. 
     613
     614After the initial iterations, we also perform outlier rejections based
     615on the consistency of the measurements.  For each star, we use a two
     616pass outlier clipping process.  We first define a robust median and
     617sigma from the inner 50\% of the measurements.  Measurements which are
     618more than 5$\sigma$ from this median value are rejected, and the mean
     619\& standard deviation (weighted by the inverse error) are
     620recalculated.  We then reject detections which are more than 3$\sigma$
     621from the recalculated mean. 
     622
     623Suspicious stars are also exclude from the analsis.  We exclude stars
     624with reduced $\chi^2$ values more than 20.0, or more than 2$\times$
     625the median, whichever is larger.  We also exclude stars with standard
     626deviation (of the measurements used for the mean) greater than
     627\note{is this true?} 0.005 mags or 2$\times$ the median standard
     628deviation, whichever is greater. 
     629
     630Similarly for images, we exclude those with more than 2 magnitudes of
     631extinction or for which the deviation greater of the zero points per
     632star are than 0.075 mags or 2$\times$ the median value, whichever is
     633greater.  These cuts are somewhat conservative to limit us to only
     634good measurements.  The images and stars rejected above are not used
     635to calculate the system of zero points and mean magnitudes.  These
     636cuts are updated several times as the iterations proceed.  After the
     637iterations have completed, the images which have been reject are
     638calibrated based on their overlaps with other images.
     639
     640We overweight the ubercal measurements in order to tie the relative
     641photometry system to the ubercal zero points.  Ubercal images and
     642measurements from those images are not allowed to float in the
     643relative photometry analysis.  Detections from the Ubercal images are
     644assigned weights of 10x their default (inverse-variance) weight.  The
     645calculation of the formal error on the mean magnitudes propagates this
     646additional weight, so that the errors on the Ubercal observations
     647dominates where they are present. \note{do we drop this when
     648  calculating the final mean mags?}
     649% \note{do I need to present the math?}
     650\[ \mu = \frac{\sum m_i w_i \sigma_i^{-2}}{\sum w_i \sigma_i^{-2}} \]
     651\[ \sigma_\mu = \frac{\sum w_i^2 \sigma_i^{-2}}{(\sum w_i \sigma_i^{-2})^2} \]
     652
     653The calculation of the relative photometry zero points is performed
     654for the entire $3\pi$ data set in a single, highly parallelized
     655analysis.  As discussed above, the measurement and object data in the
     656DVO database are distributed across a large number of computers in the
     657IPP cluster: for PV3, 100 parallel hosts are used.  These machines by
     658design control data from a large number of unconnected small patches
     659on the sky, with the goal of speeding queries for arbitrary chunks of
     660the sky.  As a result, this parallelization is entirely inappropriate
     661as the basis of the relative photometry analysis.  For the relative
     662photometry calculation (and later for relative astrometry
     663calculation), the sky is divided into a number of large, contiguous
     664regions each bounded by lines of constant RA \& DEC, 73 regions in the
     665case of the PV3 analysis.  A separate computer, called a ``region
     666host'' is responsible for each of these regions: that computer is
     667responsible for calculating the mean magnitudes of the objects which
     668land within its region and for determining the exposure zero points
     669for exposures for which the center of the exposure lands in the region
     670of responsibility. 
     671
     672The iterations described above (calculate mean
     673magnitudes, calculate zero points, calculate new measurements) are
     674peformed on each of the 73 region hosts in parallel.  However, between
     675certain iteration steps, the region hosts must share some information.
     676After mean object magnitudes are calculated, the region hosts must
     677share the object magnitudes for the objects which are observed by
     678exposures controlled by neighboring region hosts.  After image
     679calibrations have been determined by each region host, the image
     680calibrations must be shared with the neighboring region hosts so
     681measurement values associated with objects owned by a neighboring
     682region host may be updated.
     683
     684The completely work flow of the all-sky relative photometry analysis
     685starts with an instance of the program running on a master computer.
     686This machine loads the image database table and assigns the images to
     687the 73 region hosts.  A process is then launched on each of the region
     688hosts which is responsible for managing the image calibration analysis
     689on that host.  These processes in turn make an intial request of the
     690photometry information (object and measurement) from the 100 parallel
     691DVO partition machines.  In practice, the processes on the the region
     692hosts are launched in series by the master process to avoid
     693overloading the DVO partition machines with requests for photometry
     694data from all region hosts at once.  Once all of the photometry has
     695been loaded, the region hosts perform their iterations, sharing the
     696data which they need to share with their neighbors and blocking while
     697they wait for the data they need to receive from their neighbors.  The
     698management of this stage is performed by communication between the
     699region host.  At the end of the iterations, the regions hosts write out
     700their final image calibrations.  The master machine then loads the
     701full set of image calibrations and then applies these calibrations
     702back to all measurements in the database, updating the mean photometry
     703as part of this process.  The calculations for this last step are
     704performed in parallel on the DVO parition machines.
     705
     706With the above software, we are able to perform the entire relphot
     707analysis for the full 3$\pi$ region at once, avoiding any possible
     708edge effects.  The region host machines have internal memory ranging
     709from 96GB to 192GB.  Regions are drawn, and the maximum allowed
     710density was chosen, to match the memory usage to the memory available
     711on each machine.  A total of 9.8TB of RAM was available for the
     712analysis, allowing for up to 6000 objects per square degree in the
     713analysis.
     714
     715\note{need to discuss the process of setting the final mean magnitudes}
     716
     717For PV3, the relphot analysis was performed two times.  The first
     718analysis used only the flat-field corrections determined by the
     719ubercal analysis, with a resolution of 2x2 flat-field values for each
     720GPC1 chip (corresponding to \approx 2400 pixels), and 5 separate
     721flat-field 'seasons'.  However, we knew from prior studies that there
     722were significant flat-field structures on smaller scales.  We used the
     723data in DVO after the initial relphot calibration to measure the
     724flat-field residual with much finer resolution: 124 x 124 flat-field
     725values for each GPC1 chip (40x40 pixels per point).  \note{show the
     726  flat-field residual images, discuss the features?}.  We then used
     727\node{setphot} to apply this new flat-field correction, as well as the
     728ubercal flat-field corrections, to the data in the database.  At this
     729point, we re-ran the entire relphot analysis to determine zero points
     730and to set the average magnitudes.
     731
     732For stacks and warps, the image calibrations were determined after the
     733relative astrometry was performed on the individual chips.  Each stack
     734and each warp was tied via relative photometry to the average
     735magnitudes from the chip photometry.  In this case, no flat-field
     736corrections were applied.  For the stacks, such a correction would not
     737be possible after the stack has been generated because multiple chip
     738coordinates contribute to each stack pixel coordinate.  For the warps,
     739it is in principle possible to map back to the corresponding chip, but
     740the information was not available in the DVO database, and thus it was
     741not possible at this time to determine the flat-field correction
     742appropriate for a given warp.  This latter effect is one of several
     743which degrade the warp photometry compared to the chip photometry at
     744the bright end.  \note{recommendation}
    479745
    480746\section{Astrometry Analysis}
Note: See TracChangeset for help on using the changeset viewer.