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