The Pan-STARRS1 Database and Data Products

For nearly 4 yr, from 2010 May through 2014 March, the 1.8 m Pan-STARRS1 telescope (PS1) was used to perform a set of astronomical surveys with wide-ranging scientific goals. The largest portion of the observing time (56%) was used for the so-called 3π Survey, covering the three-quarters of the sky north of −30° decl., easily observable by PS1 from its site on the summit of Haleakala on the Hawaiian island of Maui. The wide-field optical design of the telescope (Hodapp et al. 2004) allowed PS1 to observe most of the 3π Survey area in each of five filters (${g}_{{\rm{P}}1}$, ${r}_{{\rm{P}}1}$, ${i}_{{\rm{P}}1}$, ${z}_{{\rm{P}}1}$, ${y}_{{\rm{P}}1}$) between 10 and 15 times. Another 25% of the observing time was dedicated to the Medium-Deep (MD) Survey, in which 10 fields were repeatedly observed over the course of the 4 yr mission. The Pan-STARRS1 Gigapixel Camera (GPC1), consisting of an 8 × 8 grid of 4846 × 4868 pixel CCDs covering roughly 7 deg², has a pixel scale of 0257. The telescope optics and the natural seeing of the site result in good image quality which is fully sampled by the GPC1 pixels: 75% of the 3π Survey images have FWHM values less than (151, 139, 134, 127, 121) for (${g}_{{\rm{P}}1}$, ${r}_{{\rm{P}}1}$, ${i}_{{\rm{P}}1}$, ${z}_{{\rm{P}}1}$, ${y}_{{\rm{P}}1}$), with a floor of ∼07.

This is the sixth in a series of seven papers that describe the Pan-STARRS1 Surveys, the data processing algorithms, calibration, and the resulting data products. Chambers et al. (2016, Paper I) describe the Pan-STARRS1 Surveys, an overview of the Pan-STARRS1 System, the resulting image and catalog data products, a discussion of the overall data quality and basic characteristics, and a summary of important results. Magnier et al. (2020a, Paper II) describe how the various data processing stages of the Pan-STARRS Image Processing Pipeline (IPP) are organized and implemented. Waters et al. (2020, Paper III) describe the details of the pixel processing algorithms, including detrending, warping, and adding (to create stacked images) and subtracting (to create difference images), and the resulting image products and their properties. Magnier et al. (2020b, Paper IV) describe the details of the source detection and photometry, including point-spread-function (PSF) and extended source fitting models, and the techniques for forced photometry measurements. Magnier et al. (2020c, Paper V) describe the final calibration process and the resulting photometric and astrometric quality. This paper (Paper VI) describes the Pan-STARRS1 database, the data products, and details of their organization in the Pan-STARRS1 database. M. Huber et al. (2020, in preparation, Paper VII) will describe the MD Survey in detail, including the unique issues and data products specific to that survey.

In this article, we use the following typefaces to distinguish different concepts:

• 1.  
  Small caps for the analysis stages.
• 2.  
  Italics for database tables and columns.
• 3.  
  Fixed-width font for program names, variables, and miscellaneous constants.

The Pan-STARRS Project teamed with Alex Szalay's database development group at The Johns Hopkins University (JHU) to undertake the task of providing a publicly accessible database for Pan-STARRS1 (Heasley 2008). The JHU team was the major developer of the Sloan Digital Sky Survey (SDSS) public database (Thakar et al. 2003), and it was an early goal of the Pan-STARRS team to reuse as much of the existing software as possible. However, for a number of reasons, including the much larger size of the Pan-STARRS1 data set, the wide variety of image and measurement types, and the importance of temporal information, major changes to the code base were required. Like the SDSS database, the database implementation for Pan-STARRS1 is based on the Microsoft SQL Server product line, with supporting code forked from the SDSS Catalog Archive Server Jobs System (CasJobs). Staying with SQL Server allows the use of a wealth of software developed for SDSS, including the Hierarchical Triangular Mesh tools (Szalay et al. 2007). The system developed for Pan-STARRS1 is called the Published Science Products Subsystem, or PSPS (Heasley et al. 2006).

As a widely used database engine, the Microsoft SQL Server provides a robust tool to define, build, and query the full database. The engine implements the SQL relational database language: data within different tables of the database are related to data in other tables by common fields, or indexes. In the PSPS implementation, the relationships are largely hierarchical: many measurements are linked to the images from which they came; associated measurements from the same astrophysical object are linked together to those objects. The tables use unique indexes to form these relationships, as detailed throughput this article.

The most significant challenge for the PSPS relative to the SDSS database implementation was the need to address the very large volume of Pan-STARRS1 data. The single monolithic database design of SDSS could not scale to the level needed for PS1 data. While SQL Server does not have (at present) a cluster implementation, a bespoke version can be crafted using a combination of distributed partition views and data slices (Heasley 2008). Partitioning data into smaller databases spread over multiple server machines allows the information to be presented to the users as a single, unified table.

The Pan-STARRS data released to the community has been processed several times. All data is processed immediately by the data analysis system in order to discover moving and transient objects. This nightly science processing is streamlined and designed to allow fast access to the results by the Pan-STARRS1 Moving Object Processing System (MOPS; Denneau et al. 2013) and the PS1 science consortium, typically within a few hours after observation, for the discovery of moving objects, supernovae, and other time-sensitive transients. We refer to the nightly science processing as Processing Version 0 (PV0). On longer timescales, large portions of the data have been reprocessed, either for internal use or for external release. The 3π Survey data spans >4 yr of observations (2010–2014, with some observations in 2009 and 2015), a time during which the IPP was actively being developed and improved. To make a consistent set of data, both for internal use as well as for the public release, all of the raw images were reprocessed from scratch using a specific revision number of the IPP code. During the survey, the 3π Survey data were reprocessed twice for internal access by the consortium members, making use of improvements to the calibrations and the processing algorithms. These internal releases are considered PV1 and PV2. The data released to the public in DR1 and DR2 represent a third full-scale reprocessing of the data, PV3.

This paper covers multiple data releases. The first Pan-STARRS1 data release (DR1, database opened to public in 2016 December) covers the 3π stack images and the static sky catalog. The DR1 image products are deep stacked images along with ancillary data including signal, masks, variance, and number maps. The DR1 catalog data products available from the PSPS include the PS1 static sky 3π catalog. Source properties are organized into several tables, as described in Table 1; only tables referring to the static results, without time domain information, are included in DR1.

Data Release 2 (DR2, database opened to public in 2019 January), adds more of the PS1 image products from the 3π Survey, including the single-epoch warp images and their ancillary data, such as signal, masks, and variance maps. DR2 provides the Detection tables and Forced* ¹³ tables, containing the single-epoch source detections and the forced photometry. DR2 also contains numerous improvements to the data products in DR1, which it supersedes. Future data releases are anticipated to provide the 3π diff image products and catalogs and analogous data products for the MD surveys.

Public access to the Pan-STARRS data is through the web server located at https://panstarrs.stsci.edu and is hosted by the Barbara A. Mikulski Archive for Space Telescopes (MAST) at STScI. MAST provides the access point for downloading different pixel data products and their associated metadata and source catalogs. This includes FITS images, FITS and JPEG image cutouts, scriptable image access, color JPEG images, and an interactive image browser with catalog overlays through the MAST portal and the MAST PS1 image cutout server. In addition, MAST provides a simple web-based interface to access the Pan-STARRS catalog database. Full database access to the Pan-STARRS tables is available through the CasJobs interface (see description at https://mastweb.stsci.edu/mcasjobs). CasJobs emulates local free-form SQL access in a web environment and provides both synchronous and asynchronous query execution. The interface can execute complex, large queries of the PS1 (DR1/DR2) catalogs, with results saved to a private space allocated to each registered user. The Pan-STARRS catalog database accessible through CasJobs contains calibrated catalogs of photometric and astrometric parameters for single-epoch exposures, stacks, difference images, and forced photometry. The database schema for the Pan-STARRS catalog database is briefly described in Section 7 and is fully expanded in Appendix D. Examples of queries are described in Appendix A.

The Pan-STARRS1 catalog database schema is organized into four sections:

• 1.  
  Fundamental Data Products. These are attributes that are calculated from either detrended but untransformed pixels or warped pixels. It should be noted that, once in the database, the instrumental fluxes and magnitudes have been subject to recalibration, as have the sky coordinates. Because of these recalibrations on the catalogs, the catalog values are to be preferred to making a new measurement directly from the available released pixel data, and care should be taken when using the recalibrated astrometry with the original images (see Table 2).
• 2.  
  Derived Data Products. These are higher-order science products that have been calculated from the fundamental data products, such as proper motions and photometric redshifts. These data products are not yet available and will come in later data releases.
• 3.  
  Observational Metadata. These metadata provide detailed information about the individual exposures (e.g., information like exposure time, filter used, etc.) or about which exposures went into an image combination (stacks and diffs), as well as information such as detection efficiencies.
• 4.  
  System Metadata. These tables have fixed information about the system and the database itself, primarily descriptions of various flags and their bits, but also for other metadata such as filter information.

Various database "Views" are also constructed as an aid to the user for standard types of queries. Views act like tables and primarily consist of joins of different commonly used tables, in order to simplify queries. Views are also used to join slices of tables (sliced by area of sky) into a full sky view. For example, "Detection" is a view of 32 Detection tables, but the individual tables are hidden from the user. For more information on views, including the currently defines ones, see Table 8.

This paper covers the data products and schema for the 3π data releases, though most details also apply to the MD fields. Additional documentation is available together with the data products through MAST.

This section presents a condensed version of the flow of data starting with raw image processing by the Pan-STARRS IPP and ending with the steps used to generate the PSPS database. The description includes an overview of the various terms used to describe different data products. For the full description of these steps, see Paper II. A flowchart of the whole process is shown in Figure 1.

Zoom In Zoom Out Reset image size

Exposures are first processed by the IPP, producing measurements of the sources in the individual images, stacks, and difference images. These measurements are then ingested into an instance of the "Desktop Virtual Observatory" database system (DVO, described briefly in Section 5.2 and more extensively in Paper V). The DVO database is then calibrated (Paper V). Next, the IppToPsps combines the measurements with the calibrations and transforms them into the appropriate format for the PSPS. Data in this form are loaded into the PSPS database at the University of Hawaii's Institute for Astronomy (IfA). The PSPS database is then copied to STScI and made available to the users.

5.1. Processing Stages

Processing with the IPP takes place in several stages. Because the organization of the PSPS database is tied to these processing stages, we describe them in some detail here. For further information, see Paper II for the overall analysis sequence, Paper III for the details in the detrending and other pixel manipulation, Paper IV for the source detection and characterization, and Paper V for the photometric and astrometric calibration.

5.1.1. Download and Registry of Images

Before processing of images can take place, they must first be transferred to the IPP cluster from the summit and registered in a metadata database to ensure that all of the >1.3 million images taken by Pan-STARRS have been properly handled. This is represented as the "image" $\to$ "ipp processing" step in Figure 1. The IPP uses an internal database to track all parts of the image processing. This database keeps basic metrics relevant to each stage, including details on what type of image was taken, when an image was processed, how long processing took, flags and other metrics on the quality, etc. This internal processing database is referenced to in this paper as the "GPC1" database.

5.1.2. Chip and Camera Stages

The chip stage takes the raw images—generally 60 FITS files, one FITS file per orthogonal transfer array (OTA)—and detrends them, one chip per computing job. Dark, flat, bias, background, and other corrections, as described in Paper III, are applied to each chip image, followed by source detection and photometry using the psphot program (Paper IV). Next, the camera stage combines the outputs of the chip stage, performs basic astrometry on the detected sources, and generates a binary FITS table, called an smf file, holding the catalog information for the entire exposure. These files are later ingested into a DVO-style database for internal use. These two stages are represented as the "ipp processing" $\to$ "camera" steps in Figure 1. Camera-stage products are available to the user in the PSPS "Detection" tables, starting with DR2.

5.1.3. Warp Stage

The next step, the warp stage, is represented as "camera" $\to$ "stacks" in Figure 1. The warp stage geometrically transforms the output images from the chip stage to a common pixel grid defined on a tangential R.A./decl. plane, with 025 pixels. The output images, called "skycells," cover the entire sky; thus, an image from a PS1 exposure can be split and projected onto a common layout for its portion of the sky. For 3π, the skycell tessellation ¹⁴ is called Rings.V3 and is described in detail in Paper II. This tessellation subdivides the sky into projection cell rings with centers at constant decl. Each projection cell is ∼40 × ∼40, subdivided into 10 × 10 skycells, each with 60'' of overlap on a side, yielding square image with size ranging from 6240 to 6500 pixels on a side. All image data products beyond warp (stacks/forced warps/diffs/ etc.) are laid out in skycells as well.

The warp image products are available to users via MAST for the 3π Survey as part of DR2.

5.1.4. Stack, Staticsky, Skycal Stages

There are three stack-related stages: stack, staticsky, and skycal. The stack stage generates the stacked images, staticsky generates the source catalogs files, while skycal calibrates the source catalogs. All of the stack-related stages are represented as "stacks" in Figure 1.

Stacks are generated by adding together warp skycells, with bad-pixel rejection and internal calibration as described in Paper III. Depending on the survey, stacks may be generated from different sets of raw exposures. For the deepest possible stacks, essentially all available exposures are combined, with only weak cuts on the data quality. Stacks may also be generated with a constraint on the image quality of the input exposures in order to yield a deep reference image with good image quality. In order to limit contamination from ongoing transient events, stacks may also be generated with constraints on the time range of the input exposures: out-of-season stacks would include only exposures not taken within a given year or period to act as a reference for transient events within that period. The different stack types are listed in the StackType table in the PSPS database. For the DR1 and DR2 3π databases, only the DEEP_STACK stack type is used, i.e., all available warps of sufficiently good quality for a given skycell and filter within the 3π Survey data set are used to generate the stacks, yielding one stack per skycell per filter. Mask images, variance images, and related pixel images are also generated for each stack.

Once each stack image is created, source detection and characterization, including galaxy morphological analysis, are performed by the staticsky stage. The source analysis is run on all five filters at once. PSF photometry is forced for sources that are detected in at least two filter images on the other filter images for which the source was not detected above the 5σ threshold. This forced photometry is also performed for sources detected in only the ${y}_{{\rm{P}}1}$ band.

Aperture photometry, for a series of circular apertures specified by SDSS (Stoughton et al. 2002), is performed on the raw stacks and also on stack images that have been convolved to a common 6 pixel FWHM, and again to a common 8 pixel FWHM. These latter seeing-matched images are only kept in memory for the analysis and are not written to disk. Up to nine of the SDSS apertures are used for this measurement: R3 (r = 103), R4 (r = 176), R5 (r = 300), R6 (r = 463), R7 (r = 743), R8 (r = 1142), R9 (r = 1820), R10 (r = 2820), and R11 (r = 4421). Note that the measurement is performed in apertures with the same angular diameter as used for SDSS, which necessarily results in different radii in pixels from those used by SDSS apertures (see Table 7 in Stoughton et al. 2002). For more details on the photometric analysis of the stack images, see Paper IV.

Catalog files, one per filter, are generated with sources spatially matched between filters using a 5 pixel (125) correlation radius. Sources matched as across filters are linked in the output catalog by the detection ID. The skycal stage calibrates the staticsky catalogs relative to the reference catalog. The calibrated catalog files are later ingested into the DVO database and then into the PSPS database. Due to the overlap between skycells, sources that land in the overlaps can be reported two, three, or four times in the DVO and PSPS database. See the discussion in Section 7.4.2 regarding the "primary" and "best" stack measurements.

Stack data products are available for the 3π Survey as part of DR1 and DR2. Stack image products are available to users via MAST, and Stack-related tables are available in the PSPS database.

5.1.5. Forced Warp Photometry Stage

Sources that are detected in the stack images are used to measure forced photometry on each of the input warps in the forced warp photometry stage. Two types of forced photometry analysis are performed on the warp exposures: PSF photometry and galaxy model analysis.

In the forced warp photometry stage, the positions of sources located in the deep stacks are used to fix the position in the warp images. The software then measures the PSF model flux at those positions on each of the individual warps. This measurement also yields the Kron and aperture fluxes for the warp image at that location. The catalogs generated by this process are ingested into the DVO database and average values are then calculated. Note that the fluxes on the warps for faint objects may be insignificant or even negative; the average values are calculated using all flux values (both positive and negative) properly weighted by the detection flux errors. Only measurements for which the warp pixels were excessively masked are rejected in this average flux calculation. The individual measurements and the averages are translated by the IppToPsps stage into the ForcedWarp* tables for the PSPS. For the 3π Survey, these tables are available starting with DR2.

For extended sources, galaxy models are fitted on the stack images. These models are then used as a seed to determine galaxy models for each warp image. The position, aspect ratio, and (where appropriate) Sérsic radius are kept fixed to the values determined for the stack image. A grid of major and minor axis values is tested around the values from the stack fit for each warp image, with the galaxy model convolved with the PSF appropriate to the specific warp image. The software reports the model normalization and χ² value at each grid point; these are combined together across all warp exposures and the interpolated minimum χ² value is used to determine a best-fit galaxy model. Due to size constraints, only the average galaxy model results are propagated to the PSPS database. These are later ingested into the PSPS database as the ForcedGalaxy* tables.

The extended source (galaxy) models described above are not applied to all sources. Galaxy models are only applied if the measured Kron magnitudes are brighter than the following limits for at least one filter: (${g}_{{\rm{P}}1}$, ${r}_{{\rm{P}}1}$, ${i}_{{\rm{P}}1}$, ${z}_{{\rm{P}}1}$, ${y}_{{\rm{P}}1}$) = (21.5, 21.5, 21.5, 20.5, 19.5). In addition, galaxy models and Petrosian fluxes are only measured for skycells with centers outside of a Galactic plane exclusion zone defined for the 3π Survey as

$$\begin{eqnarray*}&&| b| \gt {b}_{0}+{r}_{b}{e}^{\tfrac{-{l}^{2}}{2{\sigma }_{b}^{2}}},\end{eqnarray*}$$

where b₀ = 20°, r_b  = 15°, and σ_b  = 50° and l, the Galactic longitude, is constructed to have a domain of −180° to +180°. Thus, both apparently stellar and nonstellar sources outside of the dense portions of the Galactic plane and bulge have galaxy models and Petrosian fluxes measured (see full discussion in Paper IV).

5.1.6. Diff Stage

Difference images are generated by the IPP in order to detect transient and moving objects. Several types of difference images may be generated by the IPP depending on the type of images that are involved in the subtraction. The WARP_WARP diffs are generated by subtracting warps from a pair of exposures, usually taken within a short period of time; these are primarily used by the nightly science processing and the MOPS analysis for inner solar system sources and for transient detections from the 3π Survey data. STACK_STACK diffs are generated by subtracting a deep reference stack from a stack of multiple exposures taken over a shorter period. The STACK_STACK diffs are used for supernova discovery in the MD survey fields with eight exposures taken in sequence and stacked to make a more sensitive single-epoch observation. The WARP_STACK diffs were generated for the 3π Survey by combining warps from single exposures with a deep reference stack. These diffs are also used for MOPS and transient discoveries, and will be provided for the full 3π Survey as a temporal reference. There is one diff image for each single exposure within the 3π Survey. Finally, STACK_WARP diffs could be made in principle but are not in practice used by the IPP.

For the difference image analysis, the input images (stack or warp) are convolved to have similar PSFs (Waters et al. 2020) and one subtracted from the other. Sources are detected on the difference image, basic photometry is performed on the sources, and diff catalog files are created. The diff catalog files are then ingested into the diff DVO and later ingested into the PSPS. The results from this stage of processing include diff catalog files, which will be available in a future release (nominally DR3). At this time, it is undecided if, as part of DR3, the complete collection of PV3 difference images will be stored at MAST or if they will be generated on demand. Within the IPP, difference images are generally stored on disk only for a short period of time (days to weeks) in order to save on storage space. When needed, historical difference images are regularly regenerated based on stored results (difference kernels and PSF models). MAST may rely on this process for DR3.

5.2. DVO Database Steps

5.3. IppToPsps Steps

The DVO database contains the calculated astrometric and photometric calibrations and average properties of the astronomical objects but only a subset of the information recorded by the IPP in the output catalog files. It is therefore necessary, when building the PSPS database, to combine the calibrations from the DVO database with the full set of data from the individual smf and cmf catalog files. It is also necessary to extract the average quantities from the DVO database to be uploaded to the PSPS database. The IppToPsps system is responsible for both of these actions.

The IppToPsps system extracts the average properties from the DVO database in units of the DVO sky partition files and generates file sets called "batches" containing the information formatted according to the PSPS schema. IppToPsps generates average property batches separately for measurements from individual exposures, difference exposures, and exposures measured at the forced warp stage. In addition, for the 3π Survey DR1, mean property batches are generated for the astrometry tied to the Gaia DR1 catalog (Gaia Collaboration et al. 2016).

The IppToPsps system also extracts calibration information and calibrated measurements for the camera, stack, forced warp, and difference stages and combines those values with the raw measurements stored in the smf/cmf files. Batch files are generated for the camera-stage data for each exposure. For data from the other three stages, batches are generated for individual skycells. In the case of the stack data, the batch contains data for the stack images from all five filters. For the forced warp stage, the batch contains data from all warp epochs for a given skycell.

The batches generated by the IppToPsps are made available to the PSPS ingest system using an internal web-based interface called a "datastore." The IppToPsps software is written in Python/Jython, using the STILTS library (Taylor 2006) to interact with the FITS tables. IppToPsps also uses as MySQL database to track the processing and for temporary scratch databases. This process also queries the IPP processing database, retrieves files from the IPP cluster, and reads data from the DVO database.

Below we provide additional details on the different batch types generated by the IppToPsps system. An overview of the different batch types and associated DVO files and smf/cmf files is shown in the flowchart in Figure 2.

Zoom In Zoom Out Reset image size

Init batch (IN): Defines elements of the PSPS database structure and is the first to be ingested into PSPS. It includes the system metadata tables described in Section 7.2, with flag bits listed in Appendix C.

Object batches (OB): Populate the ObjectThin and MeanObject tables, described in more detail in Section 7.3. Each batch represents individual DVO files, which are subdivided into small rectangular patches of sky. Columns are filled from the DVO database (cpt and cps files).

Detection batches (P2): Populate the Detection tables, described in more detail in Section 7.4.1. Each batch corresponds to a single exposure from Pan-STARRS1. Columns within are filled from the DVO database (cpt and cpm files) as well as the camera stage catalog file (smf).

Stack batches (ST): Populate the stack tables, described in more detail in Section 7.4.2. Each batch corresponds to a skycell from the skycal stage. Columns are filled from the DVO database (cpt and cpm files) as well as from the corresponding skycal catalog files (cmf) for all five filters (or what is available).

Forced mean object batches (FO): Populate the ForcedMeanObject and ForcedMeanLensing tables, described in more detail in Section 7.3. Each batch contains data from individual DVO files (cpt, cps, cpy).

Forced galaxy batches (FG): Populate the ForcedGalaxyShape table, described in more detail in Section 7.3. Each batch contains data from individual DVO files (cpt, cps, cpq).

Forced warp batches (FW): Populate the ForcedWarp* tables, described in more detail in Section 7.4.3. Each batch corresponds to a different skycell, and contains all of the forced warp catalog measurements for that skycell. Each batch contains data from individual DVO files (cpt, cps, cpx) as well as from the corresponding forced warp catalog files (cmf).

Diff object batches (DO): Populate the DiffDetObject table, described in more detail in Section 7.3. Columns are filled from the DVO diff database (cpt and cps files).

Diff detection batches (DF): Populate the DiffDetection table, described in more detail in Section 7.4.4. Each batch corresponds to a difference image catalog file created in the diff stage and contains all of the skycells for a given exposure. Columns are filled from the DVO database (cpt and cpm files), and from the corresponding diff catalog file (cmf).

Gaia object batches (GO): Populate the GaiaFrameCoordinate table, linking the Gaia DR1 calibrated positions to the ObjectThin entries by objID. It is based on exactly the same DVO files as OB batches, has updated R.A. and decl. calibrated to Gaia, and ignores the rest of the DVO columns. These batches, and this table, are only present for DR1. For DR2, additional calibration improvements were made within the DVO database (see Paper V). The average property batches were regenerated, making the GO batch irrelevant for that release.

Within IppToPsps, it is possible to verify that the expected batches were generated, and to requeue and regenerate batches that failed. Batches fail for a variety of reasons, but none of the failures are terminal. Batches can fail if any of the associated mysql databases time out or are unavailable, or if there are disk or network I/O glitches or other disk/network problems. The DVO database sets the expected number of batches to generate, and failures are investigated and retried until they are resolved. Within IppToPsps, it is also possible to poll the PSPS to verify if batches have been ingested, thus closing the loop.

The PSPS consists of several parts: the data transformation layer (DXLayer), the Object Database Manager (ODM), the Workflow Manager Database (WMD), and the data retrieval layer (DRL). The user accesses the data through the DRL, using either scripts, the STScI CasJobs interface, or if the user is a Pan-STARRS1 Consortium member, the Published Science Interface (PSI). The DXLayer polls the IppToPsps datastores for new batches and prepares them for loading. The ODM is the software used to load, merge, copy, and publish the PSPS databases. The WMD is the database containing all the logs about the PSPS databases. The DRL is the intermediate layer between the client and the PSPS database. The PSI is the web-based interface for PS1 consortium members, for interacting with the DRL. Each of these components is described in more detail below, and a diagram of the process is shown in Figure 3.

Zoom In Zoom Out Reset image size

6.1. Partitioning the PSPS

The PSPS uses Distributed Partitioned Views, a mechanism that allows tables to be partitioned into files that reside in different linked servers. For the PSPS, the largest tables are partitioned into "slices," which divide the sky into decl. bands. The database tables exposed to the end users (e.g., Detection, ForcedWarpMeasurement, etc.) are composed of views combining the distributed slices. This aspect of the database design is intended to be transparent to the user, but power users may find it useful to know how the slices are subdivided. The dividing decl. cuts are defined to ensure each slice contains a similar amount of data, with the constraint that no slice spans less than a full camera footprint (33) due to the loading implementation. Partition slices are customized for each database version (e.g., 3π DR1, DR2 versus MD). Figure 4 shows how the data is partitioned across a subset of the machines. For the 3π Survey, the PSPS database is partitioned into 32 slices. Table 3 lists the names of the slices and the decl. ranges for each slice for the 3π Survey.

Zoom In Zoom Out Reset image size

Table 3. PSPS Decl. Slice Boundaries

Slice Name	Min Decl.	Max Decl.
Slice 1	−54.82	−28.68
Slice 2	−28.68	−26.41
Slice 3	−26.41	−24.12
Slice 4	−24.12	−21.88
Slice 5	−21.88	−19.55
Slice 6	−19.55	−17.20
Slice 7	−17.20	−14.78
Slice 8	−14.78	−12.24
Slice 9	−12.24	−9.64
Slice 10	−9.64	−7.00
Slice 11	−7.00	−4.29
Slice 12	−4.29	−1.40
Slice 13	−1.40	+1.38
Slice 14	+1.38	+4.13
Slice 15	+4.13	+6.91
Slice 16	+6.91	+9.78
Slice 17	+9.78	+12.70
Slice 18	+12.70	+15.72
Slice 19	+15.72	+18.79
Slice 20	+18.79	+21.93
Slice 21	+21.93	+25.24
Slice 22	+25.24	+28.59
Slice 23	+28.59	+31.95
Slice 24	+31.95	+35.44
Slice 25	+35.44	+38.98
Slice 26	+38.98	+42.73
Slice 27	+42.73	+46.73
Slice 28	+46.73	+50.90
Slice 29	+50.90	+55.41
Slice 30	+55.41	+60.62
Slice 31	+60.62	+67.83
Slice 32	+67.83	+89.99

Download table as:  ASCIITypeset image

6.2. Loading Data into PSPS

6.3. The Data Transformation Layer (DXLayer)

The DXLayer is the first stage in the PSPS to receive data from IppToPsps. This stage polls the IPP datastore interface for new batches to load and prepares them for the next step (ODM). Figure 5 shows the flowchart of the DXLayer process, and Figure 6 shows a more detailed flowchart of how batches are loaded and verified within the DXLayer and ODM. Figure 7 illustrates the merge of the batches and the flip between Warm and Cold databases. PSPS loads batches created by the IppToPsps (Section 5.3). Batches contain a manifest file that describes the batch information such as type of batch, min/max objID, MD5 checksum, and the tables to load. Batch data are stored in FITS files, which are transformed into comma-separated value (CSV) files in the DXLayer. As noted above, the batch area cannot exceed two PSPS slices or it will fail to load. The PSPS slices are constructed so that this does not happen.

Zoom In Zoom Out Reset image size

Zoom In Zoom Out Reset image size

Zoom In Zoom Out Reset image size

Zoom In Zoom Out Reset image size

6.4. The Object Data Manager (ODM)

6.5. The Data Retrieval Layer (DRL)

6.6. Published Science Interface (PSI)

Table 1 lists the 51 different database tables that make up the PSPS schema. Here we give a brief overview of the tables and indexes to help aid the user in selecting the most appropriate table for queries.

The database has a unique objID for each object detected within Pan-STARRS1 data. An object that has measurable flux at a given R.A. and decl. is defined to be a source. In general, multiple detections of an object will all share the same objID, as well as multiple detections within 1'' of that object (which might not be physically associated with that object, e.g., blended sources). A detailed description of the source deblending algorithm and its properties is beyond the scope of this work (see Paper IV). This objID is the core index used to join the object and detection tables in order to select detections associated with a given object. For example, ObjectThin has the astrometric information for the objects; one would join against the Detection table, using objID, in order to get the individual photometric attributes for all the detections of that object within the single exposures (at a given R.A. and decl.).

The index objID (and diffObjID for difference tables) is derived from R.A. and decl. While it is possible to calculate the R.A. and decl. from the objID, this is not recommended. The objID value is determined when an object is initially instantiated in the DVO database and is based on the initial astrometric solutions from individual exposures and stacks as they are ingested into the DVO database. These values are not calibrated against 2MASS or Gaia, nor are they authoritative. Because DR1 and DR2 use the same initial DVO database ingestion, the objID values are the same for the same object between the two releases. Included below is the C code for the translation between R.A. and decl. See also Figure 8.

uint64_t CreatePSPSObjectID(double ra, double dec) {

   double zh = 0.0083333;

   double zid = (dec + 90.)/zh;

   // zid : 0--180 ∗ 60 ∗ 2 = 21600 (<15 bits)

   int izone = (int) floor(zid);

   double zresid = zid - (float) izone;

   // zresid : 0.0--1.0

   uint64_t part1, part2, part3;

   part1 = (uint64_t)(izone ∗ 10000000000000LL);

   part2 = ((uint64_t)(ra ∗ 1000000.)) ∗ 10000;

   // part2 : 0--360 ∗ 1e6 = 3.6e8 (<29 bits)

   part3 = (int) (zresid ∗ 10000.0);

   // part3 : 0--10000

   // (1 bit == 30/10000'') (<14 bits)

   return part1 + part2 + part3;

}

7.1. The Main Categories of Tables

7.2. System Metadata Tables

7.3. Object-type Tables

7.4. Individual Exposure Detection-type Tables

7.5. Which R.A. and Decl. to Use?

7.6. Indexes and Joins

There are multiple columns within the schema that are indexed and designed to be used to join tables together. Generally, if a column name ends in "ID," it is designed to be joined to other tables, either to system metadata tables (examples include filterID, surveyID, ccdID) or to fundamental data tables (for example, objID, diffObjID, uniquePspsSTid). There are a few exceptions: randomID and random(stage)ID should not be used for joins, the contents of each are random numbers to aid the user in selecting repeatable random subsets of data. Also, some of the uniquePspsXXIds are only present in one table; they are used to provide unique IDs for each stage of processing but some stages (DiffDetObject, for example) only have one corresponding table and therefore nothing to join to.

Figures 9 and 10 show graphical representations of how to join various tables. On these figures, the table names are boxed, while the columns to be used to join are in ovals. For the diagram with objID in the middle, it shows that any of the boxes connected to objID can be joined to each other using objID.

Zoom In Zoom Out Reset image size

Zoom In Zoom Out Reset image size

All tables with photometric or astrometric information involving different sources or objects have an index, called objID. ObjID is only unique for the object type of tables, and is loosely based on R.A. and decl.; see Section 7 for more information. It is possible to use the objID to get a rough estimate of the R.A. and decl., but this should not be used for the definitive R.A. and decl. Use ObjectThin to get the R.A. and decl. calibrated to 2MASS, and use GaiaFrameCoordinate(for DR1) or ObjectThin(for DR2)to get the R.A. and decl. calibrated to Gaia astrometry. When available and possible, if joining two tables and they both have the same column name like uniquePspsXXId, join those two tables using the uniquePspsXXId. See Table 7 to see the uniquePsps column name. UniquePspsXXId is designed to be unique; specifically for the cases when there are multiple detections that are sufficiently close by, they will have the same objID but different uniquePspsXXIds.

Table 7. Unique Indices for Various PSPS Tables

PSPS Table	uniquePspsID Name	Release
ObjectThin	uniquePspsOBid	DR1
MeanObject	uniquePspsOBid	DR1
Detection	uniquePspsP2id	DR2
DiffDetection	uniquePspsDFid	DR2
DiffDetObject	uniquePspsDOid	DR2
ForcedGalaxyShape	uniquePspsFGid	DR2
ForcedMeanObject	uniquePspsFOid	DR1
ForcedMeanLensing	uniquePspsFOid	DR1
ForcedWarpMeasurement	uniquePspsFWid	DR2
ForcedWarpExtended	uniquePspsFWid	DR2
ForcedWarpLensing	uniquePspsFWid	DR2
ForcedWarpMasked	uniquePspsFWid	DR2
GaiaFrameCoordinate	uniquePspsGOid	DR1
StackObject* (2 tables)	uniquePspsSTid	DR1
StackApFlx* (4 tables)	uniquePspsSTid	DR1
StackModelFit* (4 tables)	uniquePspsSTid	DR1
StackPetrosian	uniquePspsSTid	DR1

Download table as:  ASCIITypeset image

It is possible to join every detection, no matter what stage of processing it is from, back to the original exposure(s) and to the OTAs. Figure 10 shows how to do this. For each stage of processing, there is an associated (stage)imageID that is mapped back to the imageID via tables of the name (stage)ToImage. For example, if one wanted to find out which exposures contributed to a detection in StackObjectThin, they would join to StackToImage using the stackImageID. This allows the user to find data within the database as well as to find out the corresponding images to download from MAST.

7.7. NULLS as −999

7.8. Tables and Views

The 3π Survey, described in detail in Chambers et al. (2016), covers three-quarters of the sky (decl. > −30°) in five bands (${g}_{{\rm{P}}1}$, ${r}_{{\rm{P}}1}$, ${i}_{{\rm{P}}1}$, ${z}_{{\rm{P}}1}$, ${y}_{{\rm{P}}1}$), with approximately 60 exposures per patch of sky. For various reasons, a very tiny fraction of the data does not make it into the PSPS database. Some data were intentionally skipped because of poor data quality or other problems; some data failed to process due to glitches or software bugs, some of which may be addressed in a future reanalysis (PV4 or other). We present here the different causes (of which we are aware) for data to be skipped or missed. This section lists the numbers of exposures, skycells, or batches that were processed in each stage, including counts for what were expected and as well as counts for known faults and quality issues (see also Tables 9 and 10).

8.1. Building the 3π DVO Database

8.2.  IppToPsps Stage

8.3. Loading into PSPS

The Pan-STARRS database contains 10,723,304,629 objects. It is the largest data release from the largest digital sky survey to date, distilling the information from 1.6 PB of images and tables into a form that is accessible to the astronomical community through MAST. Nevertheless, sifting through such a large database can prove daunting, and this work is intended to describe the primary tables and quantities within the database, together with example queries. Data from Pan-STARRS have been used for myriad purposes, including detecting moving objects within the solar system (and in the case of 1I/2017 U1 ('Oumuamua), from outside it!), the analysis of tens of thousands of high-energy transient events, mapping the 3D structure of dust within our Galaxy, and studies of the large-scale structure of our universe. Yet these only scratch the surface, and it is likely that mining the database will lead to discoveries that were missed and correlations that were overlooked. As we enter the era of multimessenger astrophysics, the Pan-STARRS data products will be essential to identifying the host galaxies and electromagnetic counterparts of events detected by gravitational wave, high-energy particle, neutrino, and radio observatories. While we have provided various tools to work with this data release, we anticipate that it will spur the development of new interfaces and ways of working with high-dimensional data sets. This work will be critical to science with future surveys such as LSST. Combining this Pan-STARRS data release with other large catalogs such as GALEX, 2MASSm and Gaia will provide a rich, high-dimensional data set that will enable new scientific studies and may yield astronomical treasures that we have not even begun to imagine.

The Pan-STARRS1 Surveys (PS1) have been made possible through contributions of the Institute for Astronomy, the University of Hawai'i, the Pan-STARRS Project Office, the Max-Planck Society and its participating institutes, the Max Planck Institute for Astronomy, Heidelberg, and the Max Planck Institute for Extraterrestrial Physics, Garching, The Johns Hopkins University, Durham University, the University of Edinburgh, Queen's University Belfast, the Harvard-Smithsonian Center for Astrophysics, the Las Cumbres Observatory Global Telescope Network Incorporated, the National Central University of Taiwan, the Space Telescope Science Institute, the National Aeronautics and Space Administration under grant No. NNX08AR22G issued through the Planetary Science Division of the NASA Science Mission Directorate, the National Science Foundation under grant No. AST-1238877, the University of Maryland, Eötvös Loránd University (ELTE), the Los Alamos National Laboratory, and the Gordon and Betty Moore foundation.

This work has made use of data from the European Space Agency (ESA) mission Gaia (http://www.cosmos.esa.int/gaia), processed by the Gaia Data Processing and Analysis Consortium (DPAC, http://www.cosmos.esa.int/web/gaia/dpac/consortium). Funding for the DPAC has been provided by national institutions, in particular the institutions participating in the Gaia Multilateral Agreement.

H.F. would especially like to thank G. Hasinger for extensive LATEX help, G. Narayan for magical LATEX ninja skills, and S. Isani (Ministry of Fonts) for checking LATEX for typos (he disagrees with my font choice).

Facility: PS1 (GPC1). -

This section shows example queries for the Pan-STARRS1 DR2 database. The progression will be from simple queries to more complicated queries. SQL has no requirements on case. We adopt the standard convention of using CAPITAL LETTERS for SQL-reserved words and functions and CamelCase for the tables and columns within the PSPS database schema. The queries given below may all be run from the CasJobs tab on the MAST website using the context "PanSTARRS_DR2." Note the some of the later queries rely on myDB tables generated in the earlier queries. The names for these output tables are surrounded by square brackets in the examples. These brackets are always allowed but are required if the table name includes spaces or reserved words (see https://docs.microsoft.com/en-us/sql/relational-databases/databases/database-identifiers). Also beware that cutting and pasting in some browsers can convert the underscore characters to space.

• 1.  
  Counting the number of rows in a large table.This is an example of a simple query; it needs to be run in the slow queue. The difference between COUNT_BIG() and COUNT() is that COUNT_BIG() returns a BIGINT, while COUNT() returns an INT. The PSPS tables are so large that COUNT(), which goes up to 2.14 billion, is too small of a number. Users should choose the method of counting rows that is appropriate for their data ranges. Unless it involves large tables and large areas of sky, COUNT() is recommended. However, if the result is too large, using COUNT() will result in an arithmetic overflow exception. SELECT COUNT_BIG(objID) FROM ObjectThin.
• 2.  
  Return mean PSF magnitudes and errors for all filters (grizy) for a rectangular patch of sky. SELECT ObjectThin.objID, nDetections, raMean, decMean, gMeanPSFMag, gMeanPSFMagErr, rMeanPSFMag, rMeanPSFMagErr, iMeanPSFMag, iMeanPSFMagErr, zMeanPSFMag, zMeanPSFMagErr, yMeanPSFMag, yMeanPSFMagErr FROM ObjectThin INNER JOIN MeanObject ON ObjectThin.objID = MeanObject.objID WHERE raMean > 100. 0 and raMean < 100.1 AND decMean > 0.0 AND decMean < 0.1.This returns 3868 objects. The majority of these objects have only been detected once.
• 3.  
  Make a simple text histogram of ObjectThin.nDetections for a rectangular patch of sky. It is possible to save queries into your own personal MyDB as well as to make queries on your MyDB. Do the query from above, but save it to your MyDB as "MyDBtest." Run the following query on your MyDB (MyDB context) to make a histogram of nDetections. SELECT nDetections, COUNT(nDetections) FROM MyDBtest GROUP BY nDetections ORDER BY nDetections.The results are ordered by nDetections, and it is apparent that most of the objects have zero to two detections. The nDetections column refers to the number of times something is detected from the the individual exposures. Objects that have zero detections are so faint that they are not visible in the individual exposures but are detected in the stacks. Objects with one to two (or a few) detections might be spurious detections, moving objects, or faint objects. If the user is interested in objects that are more likely to be well measured in several epochs and also of astrophysical nature, it is best to add a restriction on nDetections. If the user is interested in the static sky and in stack photometry, it is best to do a JOIN on StackObjectThin. See the next two queries for examples of each of those types of queries.
• 4.  
  Select mean PSF magnitudes and errors for filters griyz and for a rectangular patch of sky, with a restriction of >10 nDetections. This is an example of a query to get mean PSF magnitudes and errors for all filters in a rectangular patch of sky, for objects with >10 nDetections. The reason we chose 10 detections is somewhat arbitrary and can be adjusted, but is used primarily to cut out objects for which there are only a few detections. Objects with very few detections might not be astrophysical or they might be too faint to be seen multiple times. SELECT ObjectThin.objID, raMean,decMean, gMeanPSFMag, gMeanPSFMagErr, rMeanPSFMag, rMeanPSFMagErr, iMeanPSFMag, iMeanPSFMagErr, zMeanPSFMag, zMeanPSFMagErr, yMeanPSFMag, yMeanPSFMagErr FROM ObjectThin INNER JOIN MeanObject ON ObjectThin.objID = MeanObject.objID WHER nDetections > 10 AND raMean > 100.0 AND raMean < 100.1 AND decMean > 0.0 AND decMean < 0.1 . This returns 748 objects, a significant reduction from the 3867 returned in query # 2.
• 5.  
  Select stack PSF magnitudes for all filters for a rectangular patch of sky.This is an example of a query to get stack PSF magnitudes for the same rectangular patch of sky. No restrictions on nDetections are necessary; the expectation is that sources on stacks are more likely to be astrophysical. SELECT ObjectThin.objID, raStack, decStack, gPSFMag, gPSFMagErr, rPSFMag, rPSFMagErr,iPSFMag, iPSFMagErr, zPSFMag, zPSFMagErr, yPSFMag, yPSFMagErr FROM ObjectThin INNER JOIN StackObjectThin ON ObjectThin.objID = StackObjectThin.objID WHERE raMean > 100.0 AND raMean < 100.1 AND decMean > 0.0 AND decMean < 0.1 . This returns 1806 objects.
• 6.  
  An example of finding rows with NULL values, using TOP to limit results. The PSPS uses −999 to denote NULL values. The following query returns some objects that are detected in single exposures but not in the stacks. The numbers are limited by TOP to return the first 10 rows. SELECT TOP 10 objectThin.objID, raMean, decMean, raStack, decStack, nDetections, ng, nr, ni, nz, ny, imeanpsfmag FROM objectThin JOIN MeanObject on objectThin.objID = meanObject.objid WHERE raStack = −999.
• 7.  
  Basic search using BETWEEN to limit ranges.Similar to query # 5, except uses BETWEEN to limit R.A. and decl. ranges as well as iPSFMag ranges. SELECT ObjectThin.objID, raStack, decStack, gPSFMag, gPSFMagErr, rPSFMag, rPSFMagErr,iPSFMag, iPSFMagErr, zPSFMag, zPSFMagErr, yPSFMag, yPSFMagErr FROM ObjectThin INNER JOIN StackObjectThin ON ObjectThin.objID = StackObjectThin.objID WHERE raMean BETWEEN 100.0 AND 100.1 AND decMean BETWEEN 0.0 AND 0.1 AND iPSFMag BETWEEN 18.0 AND 21.0.
• 8.  
  Using built-in functions to do a box search.ObjectThin contains Hierarchical triangular mesh information, making it possible to use the built-in function dbo.fGetObjFromRectEq(minra, mindec, maxra, maxdec) to do a rectangular search. Tables that have htm, cx,cy, cz can use this built-in function. SELECT o.objID, o.raMean, o.decMean FROM ObjectThin o, dbo.fGetObjFromRectEq(56.65, 23.92, 57.05, 24.32) AS r WHERE o.objID = r.objID.
• 9.  
  Using built-in functions to do a cone search. ObjectThin contains Hierarchical triangular mesh information, making it possible to use the built-in function dbo.fGetNearbyObjEq(ra, dec, conesize(arcmin)) to do a radial search for objects near a given ra and dec (cone search). Tables that have htm, cx, cy, cz can use this built-in function. The query below returns the objects within 0 2 of the coordinate 56.85, 24.12. Note that only one of these objects was detected in a ${g}_{{\rm{P}}1}$-band image and thus has a valid value for the ${g}_{{\rm{P}}1}$-magnitude. SELECT o.objID, raMean, decMean, gMeanPSFMag, gMeanPSFMagErr FROM ObjectThin AS o JOIN MeanObject AS m ON o.objID = m.objID JOIN dbo.fGetNearbyObjEq(56.85, 24.12, 0.2) AS n ON o.objID = n.objID.
• 10.  
  Cone search of high-fidelity stellar-like objects. We want to get all objects with R degrees of a given position that are high-fidelity stellar-like objects. We get all objects within 02 of R.A. = 334.0 and decl. = 0.0 which have mean magnitudes in griz (i.e., at least one detection in each band that can be used for the mean mag). In addition, we require QfPerfect >0.85 in all bands. We select stars with a small (<0.05) difference between Kron and PSF magnitudes. SELECT o.objID, o.raMean, o.decMean, o.raMeanErr, o.decMeanErr, o.qualityFlag, o.gMeanPSFMag, o.gMeanPSFMagErr, o.gMeanPSFMagNpt, o.rMeanPSFMag, o.rMeanPSFMagErr, o.rMeanPSFMagNpt, o.iMeanPSFMag, o.iMeanPSFMagErr, o.iMeanPSFMagNpt, o.zMeanPSFMag, o.zMeanPSFMagErr, o.zMeanPSFMagNpt, o.yMeanPSFMag, o.yMeanPSFMagErr, o.yMeanPSFMagNpt, o.rMeanKronMag, o.rMeanKronMagErr, o.nDetections, o.ng, o.nr, o.ni, o.nz,o.ny, o.gFlags, o.gQfPerfect, o.rFlags, o.rQfPerfect, o.iFlags, o.iQfPerfect, o.zFlags, o.zQfPerfect, o.yFlags, o.yQfPerfect, soa.primaryDetection, soa.bestDetection INTO mydb.[HighFidelityStarsDR2] FROM dbo.fGetNearbyObjEq(334, 0.0, 0.2 ∗ 60.0) as x JOIN MeanObjectView o on o.objID = x.ObjId LEFT JOIN StackObjectAttributes AS soa ON soa.objID = x.objID WHERE o.nDetections > 5 AND soa.primaryDetection > 0 AND o.gQfPerfect > 0.85 and o.rQfPerfect > 0.85 and o.iQfPerfect > 0.85 and o.zQfPerfect > 0.85 AND (o.rmeanpsfmag---o.rmeankronmag < 0.05).
• 11.  
  Galaxy Candidates for the K2 SN Search.The Kepler Extra-Galactic Survey (KEGS) is a program using the Kepler telescope to search for supernovae, active galactic nuclei, and other transients in galaxies. We identify galaxies in a suitable redshift range (z ≤ 0.12) a priori, which will be monitored by K2. Here is an example to select galaxies for Campaign 14. We only select objects with r ≤ 19.5, and we make a cut on (rmeanpsfmag – rmeankronmag) ≥ 0.05 in order to remove stars. We only want to use objects for which the majority of pixels were not masked, thus the cut on QFperfect ≥ 0.95. We also obtain the Petrosian radii in order to be able to select galaxies by size. SELECT o.objID, ot.raStack, ot.decStack, ot.raMean, ot.decMean, ot.ng, o.gMeanPSFMag,o.gMeanPSFMagErr,o.gMeanKronMag,o.gMeanKronMagErr, ot.nr, o.rMeanPSFMag,o.rMeanPSFMagErr,o.rMeanKronMag,o.rMeanKronMagErr, ot.ni, o.iMeanPSFMag,o.iMeanPSFMagErr,o.iMeanKronMag,o.iMeanKronMagErr, ot.nz, o.zMeanPSFMag,o.zMeanPSFMagErr,o.zMeanKronMag,o.zMeanKronMagErr, ot.ny, o.yMeanPSFMag,o.yMeanPSFMagErr,o.yMeanKronMag,o.yMeanKronMagErr, o.gQfPerfect, o.rQfPerfect, o.iQfPerfect, o.zQfPerfect, o.yQfPerfect, ot.qualityFlag, ot.objInfoFlag, sp.gpetRadius, sp.rpetRadius, sp.ipetRadius, sp.zpetRadius, sp.ypetRadius, sp.gpetR50, sp.rpetR50, sp.ipetR50, sp.zpetR50, sp.ypetR50, soa.primaryDetection, soa.bestDetection INTO mydb.[C14] FROM MeanObject AS o JOIN fgetNearbyObjEq(160.68333, 6.85167 , 8.5 ∗ 60.0) cone ON cone.objid = o.objID JOIN ObjectThin AS ot ON ot.objID = o.objID LEFT JOIN StackPetrosian AS sp ON sp.objID = o.objID LEFT JOIN StackObjectAttributes AS soa ON soa.objID = o.objID WHERE ot.ni >= 3 AND ot.ng >= 3 AND ot.nr >= 3 AND soa.primaryDetection > 0 AND (o.rMeanKronMag > 0 AND o.rMeanKronMag < = 19.5) AND (o.gQfPerfect >= 0.95) AND (o.rQfPerfect >= 0.95) AND (o.iQfPerfect >= 0.95) AND (o.zQfPerfect >= 0.95) AND (o.rmeanpsfmag---o.rmeankronmag > 0.05).
• 12.  
  Find the objID of a single object. Star CSS J030521.9+013231 (Catalina Sky Survey), 584630948352256 (GAIA) is an RR Lyrae with period = 0.55547 days and coordinates R.A. = 46.341468915923 and decl. = 1.54199810825252 (ref. GAIA DR2, 2018yCat.1345....0G). In the following, we obtain the PSF and aperture photometry light curves, both forced and unforced, for this star. (See Figure 11.) First, we generate a MyDB table containing the Gaia information for this source by running the following query against the Gaia DR2 database at MAST: SELECT source_id AS ID_GAIA, ra AS RA_GAIA, dec AS DEC_GAIA, phot_g_mean_mag AS Gmag INTO mydb.[RRL_584630948352256] FROM gaia_source WHERE source_id = 584630948352256 . Now we run the following query to extract the Pan-STARRS DR2 information: SELECT d.ID_GAIA, d.RA_GAIA as GAIARA, d.DEC_GAIA as GAIADec, d.Gmag, o.objID, o.raMean, o.decMean, o.raMeanErr, o.decMeanErr, o.qualityFlag, o.gMeanPSFMag, o.gMeanPSFMagErr, o.gMeanPSFMagNpt, o.rMeanPSFMag, o.rMeanPSFMagErr, o.rMeanPSFMagNpt, o.iMeanPSFMag, o.iMeanPSFMagErr, o.iMeanPSFMagNpt, o.zMeanPSFMag, o.zMeanPSFMagErr, o.zMeanPSFMagNpt, o.yMeanPSFMag, o.yMeanPSFMagErr, o.yMeanPSFMagNpt, o.rMeanKronMag, o.rMeanKronMagErr, o.nDetections, o.ng, o.nr, o.ni, o.nz, o.ny, o.gFlags, o.gQfPerfect, o.rFlags, o.rQfPerfect, o.iFlags, o.iQfPerfect, o.zFlags, o.zQfPerfect, o.yFlags, o.yQfPerfect, soa.primaryDetection, soa.bestDetection INTO mydb.[RRL_584630948352256_PS1] FROM mydb.[RRL_584630948352256] d CROSS APPLY dbo.fGetNearbyObjEq(46.341468915923, 1.54199810825252, 1.0/60.0) as x JOIN MeanObjectView o on o.objID = x.ObjId LEFT JOIN StackObjectAttributes AS soa ON soa.objID = x.objID WHERE o.nDetections > 8 AND soa.primaryDetection > 0 AND o.gQfPerfect > 0.85 and o.rQfPerfect > 0.85 and o.iQfPerfect > 0.85 and o.zQfPerfect > 0.85 AND (o.rmeanpsfmag---o.rmeankronmag < 0.05).
• 13.  
  Obtain the lightcurve for a given object (Detections). The query above gives an objID of 109850463414820867 for that RR Lyrae star. Knowing the objID, it is possible to query to get the lightcurve. SELECT o.ID_GAIA, o.GAIARA, o.GAIADec, o.Gmag, o.objID, o.raMean, o.decMean, d.ra, d.dec, d.raErr, d.decErr, d.detectID, d.obstime, d.exptime, d.airmass, d.psfflux, d.psffluxErr, d.psfQf, d.psfQfPerfect, d.psfLikelihood, d.psfChiSq, d.extNSigma, d.zp, d.apFlux, d.apFluxErr, d.imageID, d.filterID, d.sky, d.skyerr, d.infoflag, d.infoflag2, d.infoflag3, o.qualityFlag, o.gMeanPSFMag, o.gMeanPSFMagErr, o.gMeanPSFMagNpt, o.rMeanPSFMag, o.rMeanPSFMagErr, o.rMeanPSFMagNpt, o.iMeanPSFMag, o.iMeanPSFMagErr, o.iMeanPSFMagNpt, o.zMeanPSFMag, o.zMeanPSFMagErr, o.zMeanPSFMagNpt, o.yMeanPSFMag, o.yMeanPSFMagErr, o.yMeanPSFMagNpt, o.rMeanKronMag, o.rMeanKronMagErr, o.nDetections, o.ng, o.nr, o.ni, o.nz, o.ny, o.gFlags, o.gQfPerfect, o.rFlags, o.rQfPerfect, o.iFlags, o.iQfPerfect, o.zFlags, o.zQfPerfect, o.yFlags, o.yQfPerfect, o.primaryDetection, o.bestDetection INTO mydb.[RRL_584630948352256_PS1det] FROM mydb.[RRL_584630948352256_PS1] o JOIN Detection d on d.objID = o.objID
• 14.  
  Obtain the lightcurve for a given object (Forced photometry). Similar to the query above, except this one provides the forced photometry for the star with objID = 109850463414820867. SELECT o.ID_GAIA,o.GAIARA, o.GAIADec, o.Gmag, o.objID, o.raMean, o.decMean, fwm.detectID, fwm.obstime, fwm.exptime, fwm.airmass, fwm.Fpsfflux, fwm.FpsffluxErr, fwm.FpsfQf, fwm.FpsfQfPerfect, fwm.FpsfChiSq, fwm.zp, fwm.FapFlux, fwm.FapFluxErr, fwm.forcedWarpID, fwm.filterID, fwm.Fsky, fwm.Fskyerr, fwm.Finfoflag, fwm.Finfoflag2, fwm.Finfoflag3, o.qualityFlag, o.gMeanPSFMag, o.gMeanPSFMagErr, o.gMeanPSFMagNpt, o.rMeanPSFMag, o.rMeanPSFMagErr, o.rMeanPSFMagNpt, o.iMeanPSFMag, o.iMeanPSFMagErr, o.iMeanPSFMagNpt, o.zMeanPSFMag, o.zMeanPSFMagErr, o.zMeanPSFMagNpt, o.yMeanPSFMag, o.yMeanPSFMagErr, o.yMeanPSFMagNpt, o.rMeanKronMag, o.rMeanKronMagErr, o.nDetections, o.ng, o.nr, o.ni, o.nz,o.ny, o.gFlags, o.gQfPerfect, o.rFlags, o.rQfPerfect, o.iFlags, o.iQfPerfect, o.zFlags, o.zQfPerfect, o.yFlags, o.yQfPerfect, o.primaryDetection, o.bestDetection INTO mydb.[RRL_584630948352256_PS1forced] FROM mydb.[RRL_584630948352256_PS1] o JOIN ForcedWarpMeasurement fwm on fwm.objID = o.objID.

Zoom In Zoom Out Reset image size

• 3pi or 3π: Three Pi Survey. This survey covers 3π steradians of the sky (three-quarters of the sky), everything with decl. greater than −30°.
• DR1: Data Release 1. Covers the 3π data release for ObjectThin, MeanObject, Stack*, ForcedMean*, and related metadata tables. Covers the static sky.
• DR2: Data Release 2. 3π data release of time domain tables, including Detection, ForcedWarp*, Diff*, and related metadata.
• DVO: Desktop Virtual Observatory—written by Eugene Mangier, IPP uses this to store and manipulate catalog data.
• GPC1: Gigapixel Camera 1. This is the name of the camera that is part of the Pan-STARRS1 telescope. 1.4 gigapixels and sees 7 deg² per exposure. It is made up of 60 OTA, each with 64 cells per OTA.
• IPP: Image Processing Pipeline. Code developed to process and manage all aspects of Pan-STARRS1 processing, starting from downloading the images to the summit to generating data in the final database schema form.
• MD: Short for Medium-Deep fields. A set of 10 fields, each of which is 7 deg², observed at a high cadence, primarily to be used for searches for transient objects. These will be released at a later time.
• MOPS: Short for Moving Object Processing System. The Pan-STARRS subsystem responsible for linking detections from the IPP into discoveries of asteroids or other solar system objects.
• OTA: Orthogonal transfer array, the name of the devices that make up the GPC1 camera
• PSI: Science interface. The interface used by consortium members to access earlier versions of the data.
• PSPS: Published Science Products Subsystem—the Pan-STARRS1 databases
• PV3: Processing Version 3, refers to the processing/code iteration; this is the processing version of the first public Pan-STARRS1 data release (covers DR1–DR2).

There are eight different classes of Flag tables for the database schema. This section lists the different flags as well as their descriptions. See Section 7.2.1 for more details on flags and bitmasks, and Appendix A for some example queries.

In this section, we present the contents of all DR2 tables, along with the expected diff tables for DR3. These listings were automatically generated from the XML code used to define the PSPS tables, with light editing to clean up the formatting for some of the units and equations.

D.1. Object/Mean Object Tables

D.2. Single Exposure Detection Tables

Table D9. ObjectThin: Contains the Positional Information for Objects in a Number of Coordinate Systems

Column Name	Units	Data Type	Default	Description
objName	⋯	VARCHAR(32)	NA	IAU name for this object.
objNameHMS	⋯	VARCHAR(32)	NA	Alternate sexigesimal name for this object (DR2 only).
objPSOName	⋯	VARCHAR(32)	NA	Alternate Pan-STARRS name for this object (DR1 only).
objAltName1	⋯	VARCHAR(32)	NA	Alternate name for this object.
objAltName2	⋯	VARCHAR(32)		Altername name for this object.
objAltName3	⋯	VARCHAR(32)		Altername name for this object.
objPopularName	⋯	VARCHAR(140)		Well-known name for this object.
objID	⋯	BIGINT	NA	Unique object identifier.
uniquePspsOBid	⋯	BIGINT	NA	Unique internal PSPS object identifier.
ippObjID	⋯	BIGINT	NA	IPP internal object identifier.
surveyID	⋯	TINYINT	NA	Survey identifier. Details in the Survey table.
htmID	⋯	BIGINT	NA	Hierarchical triangular mesh (Szalay et al. 2007) index.
zoneID	⋯	INT	NA	Local zone index, found by dividing the sky into bands of decl. 1/2
				arcminute in height: zoneID = floor((90+decl.)/0.0083333).
tessID	⋯	TINYINT	0	Tessellation identifier. Details in the TessellationType table.
projectionID	⋯	SMALLINT	−1	Projection cell identifier.
skyCellID	⋯	TINYINT	255	Skycell region identifier.
randomID	⋯	FLOAT	NA	Random value drawn from the interval between zero and one.
batchID	⋯	BIGINT	NA	Internal database batch identifier.
dvoRegionID	⋯	INT	−1	Internal DVO region identifier.
processingVersion	⋯	TINYINT	NA	Data release version.
objInfoFlag	⋯	INT	0	Information flag bitmask indicating details of the photometry. Values
				listed in ObjectInfoFlags.
qualityFlag	⋯	TINYINT	0	Subset of objInfoFlag denoting whether this object is real or a likely
				false positive. Values listed in ObjectQualityFlags.
raStack	degrees	FLOAT	−999	Right ascension from stack detections, weighted mean value across
				filters, in equinox J2000. See StackObjectThin for stack epoch information.
decStack	degrees	FLOAT	−999	Decl. from stack detections, weighted mean value across
				filters, in equinox J2000. See StackObjectThin for stack epoch information.
raStackErr	arcsec	REAL	−999	Right ascension standard deviation from stack detections.
decStackErr	arcsec	REAL	−999	Decl. standard deviation from stack detections.
raMean	degrees	FLOAT	−999	Right ascension from single-epoch detections (weighted mean) in
				equinox J2000 at the mean epoch given by epochMean.
decMean	degrees	FLOAT	−999	Decl. from single-epoch detections (weighted mean) in equinox
				J2000 at the mean epoch given by epochMean.
raMeanErr	arcsec	REAL	−999	Right ascension standard deviation from single-epoch detections.
decMeanErr	arcsec	REAL	−999	Decl. standard deviation from single-epoch detections.
epochMean	days	FLOAT	−999	Modified Julian Date of the mean epoch corresponding to raMean,
				decMean (equinox J2000).
posMeanChisq	⋯	REAL	−999	Reduced chi-squared value of mean position.
cx	⋯	FLOAT	NA	Cartesian x on a unit sphere.
cy	⋯	FLOAT	NA	Cartesian y on a unit sphere.
cz	⋯	FLOAT	NA	Cartesian z on a unit sphere.
lambda	degrees	FLOAT	−999	Ecliptic longitude.
beta	degrees	FLOAT	−999	Ecliptic latitude.
l	degrees	FLOAT	−999	Galactic longitude.
b	degrees	FLOAT	−999	Galactic latitude.
nStackObjectRows	⋯	SMALLINT	−999	No. of independent StackObjectThin rows associated with this object.
nStackDetections	⋯	SMALLINT	−999	Number of stack detections.
nDetections	⋯	SMALLINT	−999	Number of single-epoch detections in all filters.
ng	⋯	SMALLINT	−999	Number of single-epoch detections in the g filter.
nr	⋯	SMALLINT	−999	Number of single-epoch detections in the r filter.
ni	⋯	SMALLINT	−999	Number of single-epoch detections in the i filter.
nz	⋯	SMALLINT	−999	Number of single-epoch detections in the z filter.
ny	⋯	SMALLINT	−999	Number of single-epoch detections in the y filter.

Note. The objects associate single-epoch detections and the stacked detections within a 1'' radius. The mean position from the single-epoch data is used as the basis for coordinates when available, or the position of an object in the stack when it is not. The R.A. and decl. for both the stack and single-epoch mean are provided. The number of detections in each filter from single-epoch data is listed, along with which filters the object has a stack detection (Szalay et al. 2007).

Download table as:  ASCIITypeset image

Table D10. MeanObject: Contains the Mean Photometric Information for Objects Based on the Single-epoch Data, Calculated as Described in Magnier et al. (2013)

Column Name	Units	Data Type	Default	Description
objID	⋯	BIGINT	NA	Unique object identifier.
uniquePspsOBid	⋯	BIGINT	NA	Unique internal PSPS object identifier.
gQfPerfect	⋯	REAL	−999	Maximum PSF-weighted fraction of pixels totally unmasked
				from g-filter detections.
gMeanPSFMag	AB	REAL	−999	Mean PSF magnitude from g-filter detections.
gMeanPSFMagErr	AB	REAL	−999	Error in mean PSF magnitude from g-filter
				detections.
gMeanPSFMagStd	AB	REAL	−999	Standard deviation of PSF magnitudes from g-filter
				detections.
gMeanPSFMagNpt	⋯	SMALLINT	−999	Number of measurements included in the mean PSF
				magnitude from g-filter detections.
gMeanPSFMagMin	AB	REAL	−999	Minimum PSF magnitude from g-filter detections.
gMeanPSFMagMax	AB	REAL	−999	Maximum PSF magnitude from g-filter detections.
gMeanKronMag	AB	REAL	−999	Mean Kron (1980) magnitude from g-filter detections.
gMeanKronMagErr	AB	REAL	−999	Error in mean Kron (1980) magnitude from g-filter
				detections.
gMeanKronMagStd	AB	REAL	−999	Standard deviation of Kron (1980) magnitudes from
				g-filter detections.
gMeanKronMagNpt	⋯	SMALLINT	−999	Number of measurements included in mean Kron
				(1980) magnitude from g-filter detections.
gMeanApMag	AB	REAL	−999	Mean aperture magnitude from g-filter detections.
gMeanApMagErr	AB	REAL	−999	Error in mean aperture magnitude from g-filter
				detections.
gMeanApMagStd	AB	REAL	−999	Standard deviation of aperture magnitudes from g-
				filter detections.
gMeanApMagNpt	⋯	SMALLINT	−999	Number of measurements included in the mean aperture
				magnitude from g-filter detections.
gFlags	⋯	INT	0	Information flag bitmask for mean object from g-filter
				detections. Values listed in ObjectFilterFlags.
rQfPerfect
...				Same entries repeated for the r, i, z, and y filters
yFlags

Note. To be included in this table, an object must be bright enough to have been detected at least once in an individual exposure. PSF, Kron (1980), and aperture magnitudes and statistics are listed for all filters.

Download table as:  ASCIITypeset image

Table D11. GaiaFrameCoordinate: PSPS Objects Calibrated Against Gaia Astrometry

Column Name	Units	Data Type	Default	Description
objID	⋯	BIGINT	NA	Unique object identifier.
uniquePspsGOid	⋯	BIGINT	NA	Unique internal PSPS object identifier.
ippObjID	⋯	BIGINT	NA	IPP internal object identifier.
batchID	⋯	BIGINT	NA	Internal database batch identifier.
gaiaFlag	⋯	INT		Information flag bitmask.
ra	degrees	FLOAT	−999	Right ascension from single-epoch detections (weighted mean) in
				equinox J2000 at the mean epoch given by epochMean and calibrated against Gaia.
dec	degrees	FLOAT	−999	Decl. from single-epoch detections (weighted mean) in equinox
				J2000 at the mean epoch given by epochMean and calibrated against Gaia.
raErr	arcsec	REAL	−999	Right ascension standard deviation from single-epoch detections.
decErr	arcsec	REAL	−999	Decl. standard deviation from single-epoch detections.

Download table as:  ASCIITypeset image

Table D12. FrameMeta: Contains Metadata Related to an Individual Exposure

Column Name	Units	Data Type	Default	Description
frameID	⋯	INT	NA	Unique frame/exposure identifier.
frameName	⋯	VARCHAR(32)	NA	Frame/exposure name provided by the camera software.
surveyID	⋯	TINYINT	NA	Survey identifier. Details in the Survey table.
filterID	⋯	TINYINT	NA	Filter identifier. Details in the Filter table.
ippChipID	⋯	INT	NA	IPP chipRun identifier.
ippCamID	⋯	INT	NA	IPP camRun identifier.
ippWarpID	⋯	INT	NA	IPP warpRun identifier.
cameraID	⋯	SMALLINT	NA	Camera identifier. Details in the CameraConfig table.
cameraConfigID	⋯	SMALLINT	NA	Camera configuration identifier. Details in the CameraConfig table.
telescopeID	⋯	SMALLINT	NA	Telescope identifier.
analysisVer	⋯	VARCHAR(100)		IPP software analysis release version.
md5sum	⋯	VARCHAR(100)		IPP MD5 Checksum.
nOTA	⋯	SMALLINT	−999	Number of valid OTA images in this frame/exposure.
photoScat	magnitudes	REAL	−999	Photometric scatter relative to reference catalog across the full FOV.
nPhotoRef	⋯	INT	−999	Number of photometric reference sources.
expStart	days	FLOAT	−999	Modified Julian Date at the start of the exposure.
expTime	seconds	REAL	−999	Exposure time of the frame/exposure. Necessary for converting listed
				fluxes and magnitudes back to measured ADU counts.
airmass	⋯	REAL	0	Airmass at midpoint of the exposure. Necessary for converting listed
				fluxes and magnitudes back to measured ADU counts.
raBore	degrees	FLOAT	−999	Right ascension of telescope boresight.
decBore	degrees	FLOAT	−999	Decl. of telescope boresight.
ctype1	⋯	VARCHAR(100)		Name of astrometric projection in R.A.
ctype2	⋯	VARCHAR(100)		Name of astrometric projection in decl.
crval1	degrees	FLOAT	−999	Right ascension corresponding to reference pixel.
crval2	degrees	FLOAT	−999	Decl. corresponding to reference pixel.
crpix1	pixels	FLOAT	−999	Reference pixel for R.A.
crpix2	pixels	FLOAT	−999	Reference pixel for decl.
cdelt1	degrees/pixel	FLOAT	−999	Pixel scale in R.A.
cdelt2	degrees/pixel	FLOAT	−999	Pixel scale in decl.
pc001001	⋯	FLOAT	−999	Linear transformation matrix element between focal plane pixel L and R.A.
pc001002	⋯	FLOAT	−999	Linear transformation matrix element between focal plane pixel M and R.A.
pc002001	⋯	FLOAT	−999	Linear transformation matrix element between focal plane pixel L and decl.
pc002002	⋯	FLOAT	−999	Linear transformation matrix element between focal plane pixel M and decl.
polyOrder	⋯	TINYINT	255	Polynomial order of astrometric fit between detector focal plane and sky.
pca1x3y0	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x3 y0) for R.A.
pca1x2y1	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x2 y1) for R.A.
pca1x1y2	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x1 y2) for R.A.
pca1x0y3	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x0 y3) for R.A.
pca1x2y0	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x2 y0) for R.A.
pca1x1y1	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x1 y1) for R.A.
pca1x0y2	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x0 y2) for R.A.
pca2x3y0	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x3 y0) for decl.
pca2x2y1	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x2 y1) for decl.
pca2x1y2	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x1 y2) for decl.
pca2x0y3	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x0 y3) for decl.
pca2x2y0	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x2 y0) for decl.
pca2x1y1	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x1 y1) for decl.
pca2x0y2	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x0 y2) for decl.
batchID	⋯	BIGINT	NA	Internal database batch identifier.
processingVersion	⋯	TINYINT	NA	Data release version.

Note. A "Frame" refers to the collection of all images obtained by the 60 OTA devices in the camera in a single exposure. The camera configuration, telescope pointing, observation time, and astrometric solution from the detector focal plane (L, M) to the sky (R.A., decl.) are provided.

Download table as:  ASCIITypeset image

Table D13. ImageMeta: Contains Metadata Related to an Individual OTA Image That Comprises a Portion of the Full Exposure

Column Name	Units	Data Type	Default	Description
imageID	⋯	BIGINT	NA	Unique image identifier. Constructed as (100 × frameID + ccdID).
frameID	⋯	INT	NA	Unique frame/exposure identifier.
ccdID	⋯	SMALLINT	NA	OTA identifier based on location in the focal plane, specific to an individual device.
photoCalID	⋯	INT	NA	Photometric calibration identifier. Details in the PhotoCal table.
filterID	⋯	TINYINT	NA	Filter identifier. Details in the Filter table.
bias	adu	REAL	−999	OTA bias level.
biasScat	adu	REAL	−999	Scatter in bias level.
sky	Jy arcsec−2	REAL	−999	Mean sky brightness.
skyScat	Jy arcsec−2	REAL	−999	Scatter in mean sky brightness.
nDetect	⋯	INT	−999	Number of detections in this image.
detectionThreshold	magnitudes	REAL	−999	Reference magnitude for detection efficiency calculation.
astroScat	arcseconds	REAL	−999	Measurement of the calibration (not astrometric error) defined to be the sum in quadrature of the
				standard deviations in the X and Y directions.
photoScat	magnitudes	REAL	−999	Photometric scatter relative to reference catalog.
nAstroRef	⋯	INT	−999	Number of astrometric reference sources.
nPhotoRef	⋯	INT	−999	Number of photometric reference sources.
recalAstroScatX	arcseconds	REAL	−999	Measurement of the recalibration (not astrometric error) in the X direction.
recalAstroScatY	arcseconds	REAL	−999	Measurement of the recalibration (not astrometric error) in the Y direction.
recalNAstroStars	⋯	INT	−999	Number of astrometric reference sources used in recalibration.
recalphotoScat	magnitudes	REAL	−999	Photometric scatter relative to reference catalog.
recalNPhotoStars	⋯	INT	−999	Number of astrometric reference sources used in recalibration.
nAxis1	pixels	SMALLINT	−999	Image dimension in x.
nAxis2	pixels	SMALLINT	−999	Image dimension in y.
psfModelID	⋯	INT	−999	PSF model identifier.
psfFWHM	arcseconds	REAL	−999	Mean PSF FWHM at image center.
psfWidMajor	arcseconds	REAL	−999	PSF major axis FWHM at image center.
psfWidMinor	arcseconds	REAL	−999	PSF minor axis FWHM at image center.
psfTheta	degrees	REAL	−999	PSF major axis orientation at image center.
momentMajor	arcseconds	REAL	−999	PSF major axis second moment.
momentMinor	arcseconds	REAL	−999	PSF minor axis second moment.
momentM2C	arcsec2	REAL	−999	Moment M2C = Mxx  − Myy .
momentM2S	arcsec2	REAL	−999	Moment M2S = 2Mxy .
momentM3	arcsec2	REAL	−999	Trefoil second moment = $\sqrt{{({M}_{{xxx}}-3{M}_{{xyy}})}^{2}+{(3{M}_{{xxy}}-{M}_{{yyy}})}^{2}}$.
momentM4	arcsec2	REAL	−999	Quadrupole second moment = $\sqrt{{({M}_{{xxxx}}-6{M}_{{xxyy}}+{M}_{{yyyy}})}^{2}+{(4{M}_{{xxxy}}-4{M}_{{xyyy}})}^{2}}$.
apResid	magnitudes	REAL	−999	Residual of aperture corrections.
dapResid	magnitudes	REAL	−999	Scatter of aperture corrections.
detectorID	⋯	VARCHAR(100)		Identifier for each individual OTA detector device.
qaFlags	⋯	BIGINT	−999	Q/A flags for this image. Values listed in ImageFlags.
detrend1	⋯	VARCHAR(100)		Identifier for detrend image 1, the static mask.
detrend2	⋯	VARCHAR(100)		Identifier for detrend image 2, the dark model.
detrend3	⋯	VARCHAR(100)		Identifier for detrend image 3, the flat.
detrend4	⋯	VARCHAR(100)		Identifier for detrend image 4, the fringe.
detrend5	⋯	VARCHAR(100)		Identifier for detrend image 5, the noise map.
detrend6	⋯	VARCHAR(100)		Identifier for detrend image 6, the nonlinearity correction.
detrend7	⋯	VARCHAR(100)		Identifier for detrend image 7, the video dark model.
detrend8	⋯	VARCHAR(100)		Identifier for detrend image 8.
photoZero	magnitudes	REAL	−999	Locally derived photometric zero point for this image.
ctype1	⋯	VARCHAR(100)		Name of astrometric projection in focal plane L.
ctype2	⋯	VARCHAR(100)		Name of astrometric projection in focal plane M.
crval1	focal plane pixels	FLOAT	−999	Focal plane L corresponding to reference pixel.
crval2	focal plane pixels	FLOAT	−999	Focal plane M corresponding to reference pixel.
crpix1	raw pixels	FLOAT	−999	Reference pixel for focal plane L.
crpix2	raw pixels	FLOAT	−999	Reference pixel for focal plane M.
cdelt1	focal plane pixels/raw pixel	FLOAT	−999	Pixel scale in focal plane x.
cdelt2	focal plane pixels/raw pixel	FLOAT	−999	Pixel scale in focal plane y.
pc001001	⋯	FLOAT	−999	Linear transformation matrix element between image pixel x and focal plane pixel L.
pc001002	⋯	FLOAT	−999	Linear transformation matrix element between image pixel y and focal plane pixel L.
pc002001	⋯	FLOAT	−999	Linear transformation matrix element between image pixel x and focal plane pixel M.
pc002002	⋯	FLOAT	−999	Linear transformation matrix element between image pixel y and focal plane pixel M.
polyOrder	⋯	TINYINT	255	Polynomial order of astrometric fit between the image pixels and the detector focal plane.
pca1x3y0	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x3 y0) for focal plane L.
pca1x2y1	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x2 y1) for focal plane L.
pca1x1y2	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x1 y2) for focal plane L.
pca1x0y3	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x0 y3) for focal plane L.
pca1x2y0	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x2 y0) for focal plane L.
pca1x1y1	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x1 y1) for focal plane L.
pca1x0y2	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x0 y2) for focal plane L.
pca2x3y0	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x3 y0) for focal plane M.
pca2x2y1	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x2 y1) for focal plane M.
pca2x1y2	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x1 y2) for focal plane M.
pca2x0y3	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x0 y3) for focal plane M.
pca2x2y0	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x2 y0) for focal plane M.
pca2x1y1	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x1 y1) for focal plane M.
pca2x0y2	⋯	FLOAT	−999	Polynomial coefficient for the astrometric fit component (x0 y2) for focal plane M.
processingVersion	⋯	TINYINT	NA	Data release version.

Note. The characterization of the image quality, the detrends applied, and the astrometric solution from the raw pixels (X, Y) to the detector focal plane (L, M) are provided.

Download table as:  ASCIITypeset images: 1 2

Table D14. Detection: Contains Single-epoch Photometry of Individual Detections from a Single Exposure

Column Name	Units	Data Type	Default	Description
objID	⋯	BIGINT	NA	Unique object identifier.
uniquePspsP2id	⋯	BIGINT	NA	Unique internal PSPS detection identifier.
detectID	⋯	BIGINT	NA	Unique detection identifier.
ippObjID	⋯	BIGINT	NA	IPP internal object identifier.
ippDetectID	⋯	BIGINT	NA	IPP internal detection identifier.
filterID	⋯	TINYINT	NA	Filter identifier. Details in the Filter table.
surveyID	⋯	TINYINT	NA	Survey identifier. Details in the Survey table.
imageID	⋯	BIGINT	NA	Unique image identifier. Constructed as (100 × frameID + ccdID).
randomDetID	⋯	FLOAT	NA	Random value drawn from the interval between zero and one.
dvoRegionID	⋯	INT	−1	Internal DVO region identifier.
obsTime	days	FLOAT	−999	Modified Julian Date at the midpoint of the observation.
xPos	raw pixels	REAL	−999	PSF x-center location.
yPos	raw pixels	REAL	−999	PSF y-center location.
xPosErr	raw pixels	REAL	−999	Error in the PSF x -center location.
yPosErr	raw pixels	REAL	−999	Error in the PSF y-center location.
pltScale	arcseconds/pixel	REAL	−999	Local plate scale at this location.
posAngle	degrees	REAL	−999	Position angle (sky-to-chip) at this location.
ra	degrees	FLOAT	−999	Right ascension.
dec	degrees	FLOAT	−999	Declination.
raErr	arcseconds	REAL	−999	Right ascension error.
decErr	arcseconds	REAL	−999	Declination error.
extNSigma	⋯	REAL	0	An extendedness measure based on the deviation between PSF and Kron
				magnitudes, normalized by the PSF magnitude uncertainty.
zp	magnitudes	REAL	0	Photometric zero point. Necessary for converting listed fluxes and
				magnitudes back to measured ADU counts.
telluricExt	magnitudes	REAL	NA	Estimated Telluric extinction due to nonphotometric observing conditions.
				Necessary for converting listed fluxes and magnitudes back to measured ADU counts.
expTime	seconds	REAL	−999	Exposure time of the frame/exposure. Necessary for converting listed
				fluxes and magnitudes back to measured ADU counts.
airMass	⋯	REAL	0	Airmass at midpoint of the exposure. Necessary for converting listed
				fluxes and magnitudes back to measured ADU counts.
psfFlux	Jy	REAL	−999	Flux from PSF fit.
psfFluxErr	Jy	REAL	−999	Error on flux from PSF fit.
psfMajorFWHM	arcsec	REAL	−999	PSF major axis FWHM.
psfMinorFWHM	arcsec	REAL	−999	PSF minor axis FWHM.
psfTheta	degrees	REAL	−999	PSF major axis orientation.
psfCore	⋯	REAL	−999	PSF core parameter k, where F = F0/(1 + kr2 + r3.33).
psfQf	⋯	REAL	−999	PSF coverage factor.
psfQfPerfect	⋯	REAL	−999	PSF weighted fraction of pixels totally unmasked.
psfChiSq	⋯	REAL	−999	Reduced chi-squared value of the PSF model fit.
psfLikelihood	⋯	REAL	−999	Likelihood that this detection is best fit by a PSF.
momentXX	arcsec2	REAL	−999	Second moment Mxx .
momentXY	arcsec2	REAL	−999	Second moment Mxy .
momentYY	arcsec2	REAL	−999	Second moment Myy .
momentR1	arcsec	REAL	−999	First radial moment.
momentRH	arcsec0.5	REAL	−999	Half-radial moment (r0.5 weighting).
momentM3C	arcsec2	REAL	−999	Cosine of trefoil second moment term: ${r}^{2}\,\cos (3\theta )={M}_{{xxx}}-3{M}_{{xyy}}$.
momentM3S	arcsec2	REAL	−999	Sine of trefoil second moment: ${r}^{2}\,\sin (3\theta )=3{M}_{{xxy}}-{M}_{{yyy}}$.
momentM4C	arcsec2	REAL	−999	Cosine of quadrupole second moment: ${r}^{2}\,\cos (4\theta )={M}_{{xxxx}}-6{M}_{{xxyy}}+{M}_{{yyyy}}.$
momentM4S	arcsec2	REAL	−999	Sine of quadrupole second moment: ${r}^{2}\,\sin (4\theta )=4{M}_{{xxxy}}-4{M}_{{xyyy}}$.
apFlux	Jy	REAL	−999	Flux in seeing-dependent aperture.
apFluxErr	Jy	REAL	−999	Error on flux in seeing-dependent aperture.
apFillF	⋯	REAL	−999	Aperture fill factor.
apRadius	arcsec	REAL	−999	Aperture radius.
kronFlux	Jy	REAL	−999	Kron (1980) flux.
kronFluxErr	Jy	REAL	−999	Error on Kron (1980) flux.
kronRad	arcsec	REAL	−999	Kron (1980) radius.
sky	Jy arcsec−2	REAL	−999	Background sky level.
skyErr	Jy arcsec−2	REAL	−999	Error in background sky level.
infoFlag	⋯	BIGINT	0	Information flag bitmask indicating details of the photometry.
				Values listed in DetectionFlags.
infoFlag2	⋯	INT	0	Information flag bitmask indicating details of the photometry.
				Values listed in DetectionFlags2.
infoFlag3	⋯	INT	0	Information flag bitmask indicating details of the photometry.
				Values listed in DetectionFlags3.
processingVersion	⋯	TINYINT	NA	Data release version.

Note. The identifiers connecting the detection back to the original image and to the object association are provided. PSF, aperture, and Kron (1980) photometry are included, along with sky and detector coordinate positions.

Download table as:  ASCIITypeset images: 1 2

Table D15. ImageDetEffMeta: Contains the Detection Efficiency Information for a Given Individual OTA Image

Column Name	Units	Data Type	Default	Description
imageID	⋯	BIGINT	NA	Unique image identifier. Constructed as (100 × frameID + ccdID).
frameID	⋯	INT	NA	Unique frame/exposure identifier.
magref	magnitudes	REAL	NA	Detection efficiency reference magnitude.
nInjected	⋯	INT	NA	Number of fake sources injected in each magnitude bin.
offset01	magnitudes	REAL	NA	Detection efficiency magnitude offset for bin 1.
counts01	⋯	REAL	NA	Detection efficiency count of recovered sources in bin 1.
diffMean01	magnitudes	REAL	NA	Detection efficiency mean magnitude difference in bin 1.
diffStdev01	magnitudes	REAL	NA	Detection efficiency standard deviation of magnitude differences in bin 1.
errMean01	magnitudes	REAL	NA	Detection efficiency mean magnitude error in bin 1.
offset02	magnitudes	REAL	NA	Detection efficiency magnitude offset for bin 2.
counts02	⋯	REAL	NA	Detection efficiency count of recovered sources in bin 2.
diffMean02	magnitudes	REAL	NA	Detection efficiency mean magnitude difference in bin 2.
diffStdev02	magnitudes	REAL	NA	Detection efficiency standard deviation of magnitude differences in bin 2.
errMean02	magnitudes	REAL	NA	Detection efficiency mean magnitude error in bin 2.
offset03	magnitudes	REAL	NA	Detection efficiency magnitude offset for bin 3.
counts03	⋯	REAL	NA	Detection efficiency count of recovered sources in bin 3.
diffMean03	magnitudes	REAL	NA	Detection efficiency mean magnitude difference in bin 3.
diffStdev03	magnitudes	REAL	NA	Detection efficiency standard deviation of magnitude differences in bin 3.
errMean03	magnitudes	REAL	NA	Detection efficiency mean magnitude error in bin 3.
...
offset13	magnitudes	REAL	NA	Detection efficiency magnitude offset for bin 13.
counts13	⋯	REAL	NA	Detection efficiency count of recovered sources in bin 13.
diffMean13	magnitudes	REAL	NA	Detection efficiency mean magnitude difference in bin 13.
diffStdev13	magnitudes	REAL	NA	Detection efficiency standard deviation of magnitude differences in bin 13.
errMean13	magnitudes	REAL	NA	Detection efficiency mean magnitude error in bin 13.

Note. Provides the number of recovered sources out of 500 injected fake sources and statistics about the magnitudes of the recovered sources for a range of magnitude offsets.

Download table as:  ASCIITypeset image

D.3. Stack Tables