Index: /trunk/doc/release.2015/ps1.datasystem/datasystem.tex
===================================================================
--- /trunk/doc/release.2015/ps1.datasystem/datasystem.tex	(revision 40611)
+++ /trunk/doc/release.2015/ps1.datasystem/datasystem.tex	(revision 40612)
@@ -82,8 +82,17 @@
 \begin{abstract}
 
-The Pan-STARRS Image Processing Pipeline performs the processing
+The Pan-STARRS Data Processing System is responsible for the steps
 needed to downloaded, archive, and process all images obtained by the
-Pan-STARRS telescopes.  This article describes the overall data
-analysis system.
+Pan-STARRS telescopes, including real-time detection of transient
+sources such as supernovae and moving objects including potentially
+hazardous asteroids.  With a nightly data volume of up to 4 terabytes
+and an archive of over 4 petabytes of raw imagery, Pan-STARRS is
+solidly in the realm of Big Data astronomy.  The full data processing
+system consists of several subsystems covering the wide range of
+necessary capabilities.  This article describes the Image Processing
+Pipeline and its connections to both the summit data systems and the
+outward-facing systems downstream.  The latter include the Moving
+Object Processing System (MOPS) \& the public database: the Published
+Science Products Subsystem (PSPS).
 
 \end{abstract}
@@ -130,19 +139,19 @@
 Release 1 (DR1) on 16 December 2016.  DR1 contains the results of the
 third full reduction of the Pan-STARRS $3\pi$ Survey archival data,
-identified as PV3.  Previous reductions \citep[PV0, PV1, PV2;
-  see][]{magnier2017.datasystem} were used internally for pipeline
-optimization and the development of the initial photometric and
-astrometric reference catalog \citep{magnier2017.calibration}.  The
-products from these reductions were not publicly released, but have
-been used to produce a wide range of scientific papers from the
-Pan-STARRS 1 Science Consortium members \citep{chambers2017}.  DR1
-contained only average information resulting from the many individual
-images obtained by the $3\pi$ Survey observations.  A second data
-release, DR2, was made available \note{20 January 2019}.  DR2 provides
-measurements from all of the individual exposures, and include an
-improved calibration of the PV3 processing of that dataset.
+identified as PV3.  Previous reductions (PV0, PV1, PV2) were used
+internally for pipeline optimization and the development of the
+initial photometric and astrometric reference catalog
+\citep{magnier2017.calibration}.  The products from these reductions
+were not publicly released, but have been used to produce a wide range
+of scientific papers from the Pan-STARRS 1 Science Consortium members
+\citep{chambers2017}.  DR1 contained only average information
+resulting from the many individual images obtained by the $3\pi$
+Survey observations.  A second data release, DR2, was made available
+28 January 2019.  DR2 provides measurements from all of the individual
+exposures, and include an improved calibration of the PV3 processing
+of that dataset.
 
 This is the second in a series of seven papers describing the
-Pan-STARRS1 Surveys, the data reduction techiques and the resulting
+Pan-STARRS1 Surveys, the data reduction techniques and the resulting
 data products.  This paper (Paper II) presents a description of the
 Pan-STARRS data handling systems, with an emphasis on the Image
@@ -198,5 +207,6 @@
 %Pan-STARRS 1 Database and Data Products
 \citet[][Paper VI]{flewelling2017}
-describe the details of the resulting catalog data and its organization in the Pan-STARRS database. 
+describe the details of the resulting catalog data and its
+organization in the Pan-STARRS database.
 
 %Huber et al. 2017 (Paper VII)
@@ -218,8 +228,10 @@
 used by the IPP for regular nightly operations and for processing the
 PV3 data release, with some details on the scale of computing needed
-to reduce this large number of exposures.  Finally,
-Section~\ref{sec:discussion} presents a discussion of some of the
-lessons learned in the creation of the IPP, and its utility in
-reducing data from other cameras and telescopes.
+to reduce this large number of exposures.  
+
+% Finally,
+% Section~\ref{sec:discussion} presents a discussion of some of the
+% lessons learned in the creation of the IPP, and its utility in
+% reducing data from other cameras and telescopes.
 
 %% {\color{red} {\em Note: These papers are being placed on arXiv.org to
@@ -263,10 +275,10 @@
   ingests the calibrated measurements from the IPP, MOPS, and others
   and generates a high-availability database with web-based
-  interactions for public consumption \citet[][]{flewelling2017}.
+  interactions for public consumption \citep[][]{flewelling2017}.
 
 \end{itemize}
 Management of the above set of analysis stages takes place at the IfA
 within the scope of responsibility of the Pan-STARRS Observatory.
-Across the wider Pan-STARRS colloboration(s), additional data analysis
+Across the wider Pan-STARRS collaboration(s), additional data analysis
 operations are performed to support science results.  These
 collaboration-wide analysis operations range from those which are
@@ -331,25 +343,26 @@
 Pan-STARRS has performed several large-scale reprocessings of both the
 Medium Deep and $3\pi$ Survey data for internal consumption.  For the
-$3\pi$ Survey data, we identify these large-scale reprocessings as
-PV1, PV2, and PV3, with PV3 the analysis used for the first public
-data release, DR1.  We also refer to the nightly science analysis of
-the data as PV0.  For these reprocessing stages, the standard steps of
-\ippstage{chip} through \ippstage{warp}, plus \ippstage{stack} and
-\ippstage{diff} are performed, starting from raw data, usually using a
-single homogenous version of the data analysis procedures.  PV2 was a
-special case in which we started from the camera level products of PV1
-to speed up the turn-around to the community.  In addition to the
-analysis stages listed above which are shared with the nightly
-processing, these large-scale reprocessing analyses include additional
-processing steps.  A more detailed photometric analysis is performed
-on the stacks, including morphological analysis appropriate to
-galaxies.  The results of the stack photometry analysis are used to
-drive a forced-photometry analysis of the warp images.  These analysis
-steps are discussed in detail by
-\citet[][]{magnier2017.analysis}.  The data products from the
-camera, stack, and forced-warp photometry analysis stages
-are ingested into the internal calibration database (DVO, the Desktop
-Virtual Observatory) and used for photometric and astrometric
-calibrations \citet[see Section~\ref{sec:DVO} and][]{magnier2017.calibration}.
+$3\pi$ Survey data, we identify these large-scale reprocessings as PV1
+(Processing Version 1), PV2, and PV3, with PV3 the analysis used for
+the first public data release, DR1.  We also refer to the nightly
+science analysis of the data as PV0.  For these reprocessing stages,
+the standard steps of \ippstage{chip} through \ippstage{warp}, plus
+\ippstage{stack} and \ippstage{diff} are performed, starting from raw
+data, usually using a single homogeneous version of the data analysis
+procedures.  PV2 was a special case in which we started from the
+camera level products of PV1 to speed up the turn-around to the
+community.  In addition to the analysis stages listed above which are
+shared with the nightly processing, these large-scale reprocessing
+analyses include additional processing steps.  A more detailed
+photometric analysis is performed on the stacks, including
+morphological analysis appropriate to galaxies (model fits, Kron and
+Petrosian aperture photometry, etc).  The results of the stack
+photometry analysis are used to drive a forced-photometry analysis of
+the warp images.  These analysis steps are discussed in detail by
+\citet[][]{magnier2017.analysis}.  The data products from the camera,
+stack, and forced-warp photometry analysis stages are ingested into
+the internal calibration database (DVO, the Desktop Virtual
+Observatory) and used for photometric and astrometric calibrations
+\citet[see Section~\ref{sec:DVO} and][]{magnier2017.calibration}.
 
 \subsection{Data Access and Distribution}
@@ -379,6 +392,7 @@
 
 \begin{table*}
-\caption{GPC1 Database Schema Outline} %\vspace{-0.5cm}
+\caption{GPC1 Database Schema Outline}
 \begin{center}
+\footnotesize
 \begin{tabular}{llll}
 \hline
@@ -386,5 +400,4 @@
 {\bf Stage} & {\bf Primary Table} & {\bf Secondary Table(s)} & {\bf Key} \\% & {\bf Notes} \\
 %%D \begin{deluxetable}{llll}
-\footnotesize
 %%D   \tablecolumns{5}
 %%D   \tablewidth{0pc}
@@ -741,18 +754,38 @@
 The guess astrometry is used to match the reference catalog to the
 observed stellar positions in the focal plane coordinate system
-\citep[see][]{magnier2017.calibration}.  
+\citep[see][]{magnier2017.calibration}.  Early on in the PS1SC
+mission, the nightly processing (PV0) used a reference catalog based
+on a combination of external catalogs (2MASS, Tycho, USNO).  Later, 
+reference catalogs based on Pan-STARRS data was used.  For the $3\pi$ PV3 analysis,
+the reference catalog was based on Pan-STARRS data from the PV2
+analysis \citep[see][for more details]{magnier2017.calibration}.
 
 Once an acceptable match is found, the astrometric calibration of the
 individual chips is performed, including a fit to a single model for
-the distortion introduced by the camera optics.  After the astrometic
-analysis is completed, the photometric calibration is determined using
-the final match to the reference catalog.  At this stage,
-pre-determined color terms may be included to convert the reference
-photometry to an appropriate photometric system.  For PS1, this is
-used to generate synthetic w-band photometry for areas where no
-PS1-based calibrated w-band photometry is available.  For more
-details, see \cite{magnier2017.calibration}.  The result of these
-calibrations is stored as a single multi-extension FITS table
-containing the results from each OTA as a separate extension.
+the distortion introduced by the camera optics.  The astrometric model
+includes a set of 3rd order polynomials for the transformations from the chip
+coordinate system to the camera focal plane coordinate system and a
+single additional 3rd order polynomial transformation from the camera focal
+plane coordinate system to the tangent plane of a tangent projection.
+For the $3\pi$ PV3 analysis, the typical astrometric residuals are in
+the range of 20 - 30 milliarcseconds, sufficient to match observations
+of the same objects between different exposures.  There are, however,
+inevitable outliers.  Certain chips occasionally have systematically worse
+astrometry, with OTA XY17 notably poor in this respect.
+
+After the astrometic analysis is completed, the photometric
+calibration is determined using the final match to the reference
+catalog.  A single photometric zero point is determined for each
+exposure, with the airmass term fixed to the nominal linear slope for
+each filter.  No color terms are measured between the observed
+photometry and the reference photometry.  However, at this stage,
+pre-determined color terms may be used to transform the reference
+photometry to an appropriate photometric system.  For the PS1 nightly
+processing, the reference catalog does not include \wps\ photometry,
+so a fixed color transformation is used to generate synthetic w-band
+photometry from the \rps\ \& \ips\ photometry.  For more details, see
+\cite{magnier2017.calibration}.  The result of these calibrations is
+stored as a single multi-extension FITS table containing the results
+from each OTA as a separate extension.
 
 In addition to the astrometric and photometric calibrations, the
@@ -842,5 +875,6 @@
 \ippdbtable{warpSkyCellMap} table in the database, which contains a
 row for each skycell and OTA that overlap.  Each skycell may contain
-contributions from multiple OTAs.
+contributions from multiple OTAs; since they are similar in size, in a
+typical situation the warp is constructed from 4-6 neighboring OTAs.
 
 Once this mapping has been defined, jobs to warp the pixels onto each
@@ -914,13 +948,15 @@
 The \ippstage{stack} jobs pass the information about the input images
 and catalogs to the \ippprog{ppStack} program, which performs the
-image combinations.  See~\cite{waters2017} for details on the stack
-combination algorithm.  In addition to the standard image, mask, and
-variance produced at other stages, additional images are constructed
-with information about the contributions to each pixel.  A number
-image contains the number of input exposures used for each pixel,
-along with an exposure time map, and a weighted exposure time map that
-scales the exposure time based on the relative variance of each input.
-These images for the $3\pi$ analysis are currently available from the
-MAST image extraction tools at STSci.
+image combinations.  Input warps are combined based on a weighting
+defined by the median variance for each image; see~\cite{waters2017}
+for details on the stack combination algorithm.  In addition to the
+standard image, mask, and variance produced at other stages,
+additional images are constructed with information about the
+contributions to each pixel.  A number image contains the number of
+input exposures used for each pixel, along with an exposure time map,
+and a weighted exposure time map that scales the exposure time based
+on the relative variance of each input.  These images for the $3\pi$
+analysis are currently available from the MAST image extraction tools
+at STScI.
 
 Upon completing the generation of these images, a row is added to the
@@ -961,5 +997,10 @@
 that faint, high-redshift quasars may be detected in \yps{} band only.
 Sources detected only in \yps{} band are therefore more likely to have
-a higher false-positive rate than the other stack sources.
+a higher false-positive rate than the other stack sources.  The
+parameters of the PSF model are allowed to vary with position in the
+skycell.  The PSF model is also used to convolve the analytical galaxy
+models, which are the fitted to the observed flux distributions.
+Galaxy models include S\'ersic, DeVaucouleur, and Exponential
+profiles.
 
 The stack photometry output files consist of a set of FITS table
@@ -1010,5 +1051,5 @@
 particularly severe for the Pan-STARRS $3\pi$ survey stacks due to the
 combination of the substantial mask fraction of the individual input
-exposures, the large instrinsic image quality variations within a
+exposures, the large intrinsic image quality variations within a
 single exposure, and the wide range of image quality conditions under
 which data were obtained and used to generate the $3\pi$ PV3 stacks.
@@ -1052,5 +1093,6 @@
 skycell and filter as a single unit within the processing database,
 while individual warps are processed individually in parallel as
-separate processing jobs.
+separate processing jobs.  A separate PSF model is determine for each
+of the warp images so that the combined measurement is reliable.
 
 When processing is queued for this stage, an entry is added to the
@@ -1107,7 +1149,11 @@
 analysis measurements into a single value.  The output catalogs listed
 in the \ippdbtable{fullForceResult} table are passed to the
-\ippprog{psphotFullForceSummary} to do this averaging.  When this
-completes, an entry is added to the \ippdbtable{fullForceSummary}, and
-the \ippdbtable{fullForceRun} entry is marked as completed.
+\ippprog{psphotFullForceSummary} to calculate the averages of the
+individual warp measurements, weighted by the signal-to-noise of the
+flux measurements.  When this analysis completes, an entry is added to
+the \ippdbtable{fullForceSummary}, and the \ippdbtable{fullForceRun}
+entry is marked as completed.
+
+% flux averaging takes place in psphotFullForceSummaryReadout.c:409
 
 \subsection{Difference Images}
@@ -1115,5 +1161,5 @@
 
 Two of the primary science drivers for the Pan-STARRS system are the
-search hazardous asteroids and the search for Type Ia supernovae to
+search for hazardous asteroids and the search for Type Ia supernovae to
 measure the history of the expansion of the universe.  Both of these
 projects require the discovery of faint, transient source in the
@@ -1214,5 +1260,5 @@
 % intro
 The Pan-STARRS IPP uses an internal database system, distinct from the
-publically visible database system, to determine the association
+publicly visible database system, to determine the association
 between multiple detections of the same astronomical object and as
 part of the astrometric and photometric calibration process.  This
@@ -1228,5 +1274,5 @@
 astronomical objects; 2) measurements of those objects (from which the
 average properties are derived); 3) properties of the images which
-provided some or all of the measuements.  In addition, certain
+provided some or all of the measurements.  In addition, certain
 metadata tables define general features of the database.
 Table~\ref{tab:DVO_schema} lists the full collection of database
@@ -1236,17 +1282,4 @@
 %illustrates the schematic relationship between these types of
 %measurements.
-
-\begin{figure*}[htbp]
-  \begin{center}
- \includegraphics[width=\hsize,clip]{skypartition.png}
-  \caption{\label{fig:sky.partition} Level 3 sky paritioning.  The
-    blue grid shows the outlines of the different regions assigned to
-    separate tables in the sky partitioning scheme.  The Galactic
-    plane is shown as a solid red line while the ecliptic is shown in
-    green.  This organization of the sky duplicates that used by the
-    HST Guide Star Catalog \citep{1988IAUS..133..239J}.  
- }
-\end{center}
-\end{figure*}
 
 In the most basic implementation, a collection of measurements for
@@ -1376,5 +1409,5 @@
 The \ippdbtable{Galphot} table stores the results of the forced galaxy
 fitting analysis for each object that has been measured.  This table
-contains one row per filter and model type (Sersic, Exponential, or
+contains one row per filter and model type (S\'ersic, Exponential, or
 DeVaucouleur) if forced galaxy models have been calculate for the
 object.
@@ -1514,4 +1547,17 @@
 \label{sec:SkyPartition}
 
+\begin{figure*}[htbp]
+  \begin{center}
+ \includegraphics[width=\hsize,clip]{skypartition.png}
+  \caption{\label{fig:sky.partition} Level 3 sky paritioning.  The
+    blue grid shows the outlines of the different regions assigned to
+    separate tables in the sky partitioning scheme.  The Galactic
+    plane is shown as a solid red line while the ecliptic is shown in
+    green.  This organization of the sky duplicates that used by the
+    HST Guide Star Catalog \citep{1988IAUS..133..239J}.  
+ }
+\end{center}
+\end{figure*}
+
 Tables within DVO containing information about astronomical objects
 are partitioned on the basis of position in the sky: objects within a
@@ -1535,23 +1581,23 @@
 subdivides these declination bands in the RA direction, with spacing
 related to the stellar density.  Level 3 divides these RA chunks into
-4 - 8 smaller partitions.  This level exactly matches the HST GSC
-layout, and uses the same naming convention to identify the
-partitions: \code{n0000/0000}, etc. Level 4 further divides these
-regions by a factor of 16.  In the \ippdbtable{SkyTable}, a region at
-one level has a pointer to its parent region (the one which contains
-it) and a sequence pointing to its children (regions it contains).
-The \ippdbtable{SkyTable} enables fast lookups of the on-disk
-partitions which map to a specific coordinate on the sky.  In general,
-a single DVO will have the full sky represented with tables at a
-single level, although it is possible for mixed levels to be used.
-For the PV3 master database, the partitioning is at Level 4, resulting
-in \approx 150,000 regions to cover the full sky, of which \approx
-110,000 are used for the PV3 $3\pi$ data.  The densest portions of the
-bulge contain at most \approx 300,000 astronomical objects in the
-database files, with an associated maximum of \approx 30 million
-measurements in these files.  With the compression scheme described
-below, the largest database files are \approx 3GB, which can be loaded
-into memory in 30 seconds on the processing machines that contain
-partition data.
+4 - 8 smaller partitions (see Figure~\ref{fig:sky.partition}).  This
+level exactly matches the HST GSC layout, and uses the same naming
+convention to identify the partitions: \code{n0000/0000}, etc. Level 4
+further divides these regions by a factor of 16.  In the
+\ippdbtable{SkyTable}, a region at one level has a pointer to its
+parent region (the one which contains it) and a sequence pointing to
+its children (regions it contains).  The \ippdbtable{SkyTable} enables
+fast lookups of the on-disk partitions which map to a specific
+coordinate on the sky.  In general, a single DVO will have the full
+sky represented with tables at a single level, although it is possible
+for mixed levels to be used.  For the PV3 master database, the
+partitioning is at Level 4, resulting in \approx 150,000 regions to
+cover the full sky, of which \approx 110,000 are used for the PV3
+$3\pi$ data.  The densest portions of the bulge contain at most
+\approx 300,000 astronomical objects in the database files, with an
+associated maximum of \approx 30 million measurements in these files.
+With the compression scheme described below, the largest database
+files are \approx 3GB, which can be loaded into memory in 30 seconds
+on the processing machines that contain partition data.
 
 % parallel partitions
@@ -1561,5 +1607,5 @@
 and the location of the database partition on the disks of that
 machine.  The \ippdbtable{SkyTable} contains elements to define by ID
-the parition host to which a set of tables has been assigned.
+the partition host to which a set of tables has been assigned.
 Operations which query the database, or perform other operations on
 the database, are aware of the partitioning scheme and will launch
@@ -1574,5 +1620,5 @@
 When the parallel partitioning for a DVO instance is defined, the
 tables are randomly assigned to the partition hosts.  As a result,
-queries which span more than a single parition are likely to spread
+queries which span more than a single partition are likely to spread
 the I/O load across a large number of machines.  This parallelization
 is critical to querying and manipulating the enormous database on a
@@ -1605,5 +1651,5 @@
 The \ippdbtable{Measure} table, containing the detections of objects
 from individual exposures or stack, or the (potentially
-non-signficant) measurements from a warp, uses the 32-bit integer
+non-significant) measurements from a warp, uses the 32-bit integer
 fields \ippdbcolumn{detID} and \ippdbcolumn{imageID} to uniquely
 identify each entry.  The \ippdbcolumn{imageID} is the running
@@ -1653,5 +1699,5 @@
 sequence within the image to form a single unique 64-bit integer value.
 For detections from the stack images, the MJD is not unique, so a
-different rubrick is used to define IDs for those detections.  The
+different rubric is used to define IDs for those detections.  The
 field \ippdbcolumn{XstackDetectID} (where '\ippdbcolumn{X}' is one of
 g,r,i,z,y) is constructed from the GPC1 stack ID
@@ -1684,5 +1730,5 @@
 describe the location and size of the compressed data in the HEAP
 section; the information about the uncompressed data is moved to a
-keyword with ``Z'' prepended (e.g., ZFORM1) and an additional field is
+keyword with ``Z'' pre-pended (e.g., ZFORM1) and an additional field is
 added to define the compression algorithm (e.g., ZCTYP1).  The column
 names (e.g., TTYPE1) and units (e.g., TUNIT1) are retained in their
@@ -1694,9 +1740,9 @@
 compressed in turn (this must be the same for all columns).
 Additional header information is added to describe the block sizes and
-infomation needed to describe the HEAP data section.  The compression
+information needed to describe the HEAP data section.  The compression
 algorithms currently defined consist of the GZIP, RICE, PLIO, and
 HCOMPRESS (REFS).  For GZIP, the compression algorithm may transpose
 the byte order before compression: for floating point data of a
-similiar dynamic range, this choice may allow for better compression
+similar dynamic range, this choice may allow for better compression
 as each byte in the 4 or 8 byte floating point value is more likely to
 be similar to the same byte in other rows than to the other bytes of
@@ -1758,5 +1804,5 @@
 added to the \ippdbtable{addProcessedExp} table.
 
-After the master DVO is contructed containing the PS1 data, data from
+After the master DVO is constructed containing the PS1 data, data from
 other sources are also added to the database.  For the PV3 DVO
 database, data was added from 2MASS, WISE, Gaia DR1, and Tycho.  These
@@ -1843,7 +1889,7 @@
 \label{sec:ipp2psps}
 
-The publically-visible Pan-STARRS database is hosted by the Space
+The publicly-visible Pan-STARRS database is hosted by the Space
 Telescope Sciences Institute through their Mikulski Archive for Space
-Telescopes (MAST).  The underying database at MAST is a copy of a
+Telescopes (MAST).  The underlying database at MAST is a copy of a
 database generated at the IfA by the Published Science Products
 Subsystem (PSPS).  The construction of the PSPS version of the PS1
@@ -1940,8 +1986,8 @@
 Each task must at a minimum define a command to generate.  Commands
 may be static or dynamic.  For a task with a static command, the
-command is explicity defined in the task block (see code example in
+command is explicitly defined in the task block (see code example in
 Figure~\ref{fig:task_example}) and is identical each time the task is
 executed.  A dynamic command is defined within a special block of the
-task, called \code{task.exec}.  This block is a snipet of code (in the
+task, called \code{task.exec}.  This block is a snippet of code (in the
 \ippprog{opihi} language) which is run each time the task is executed.  The
 \code{task.exec} code may refer to variables or other data structures
@@ -1987,5 +2033,5 @@
 These options may be dynamically reset by the \code{task.exec} macro.
 Some options control the number of jobs, such as limiting the number
-of currently-outsanding jobs for a given task, or limiting the total
+of currently-outstanding jobs for a given task, or limiting the total
 number generated.  Other options can be used to control the time when
 jobs of a certain task are allowed to run.  It is also possible to
@@ -2030,5 +2076,5 @@
 
 When \ippprog{pcontrol} is provided with the name of a computer, it will attempt
-to make an connection to that machine via ssh (or rsh?).  When a
+to make an connection to that machine via ssh.  When a
 connection is made, the remote shell is used to run a special
 interface program call \ippprog{pclient}.  This program accepts
@@ -2036,8 +2082,8 @@
 individual commands in the local shell environment.  A single ssh
 connection to a remote host keeps a single \ippprog{pclient} shell running for a
-somewhat arbirarly long time, excuting many shell commands as needed.
+somewhat arbitrarly long time, executing many shell commands as needed.
 This architecture avoids wasting overhead making the ssh connection to
 the remote machine each time a command is executed, allowing for rapid
-excution of many commands.  As a result, a single job within the IPP
+execution of many commands.  As a result, a single job within the IPP
 architecture is allowed to be very light and short running if needed.
 
@@ -2255,5 +2301,5 @@
 ippstage{diff} analysis stage.
 
-Once observations have been completed for the night (signalled by the
+Once observations have been completed for the night (signaled by the
 end-of-night dark exposures that are taken each morning after the
 telescope closes), and the script has generated all \ippstage{diff}
@@ -2321,5 +2367,5 @@
 challenge of storing and managing the large volume of data that is
 generated by the GPC1 camera.  The \ippprog{Nebulous} system was
-designed to aid in thie process.  \ippprog{Nebulous} is not a file
+designed to aid in this process.  \ippprog{Nebulous} is not a file
 system per-se, but only a method of tracking the locations of files
 within the file system, and of tracking duplicate copies of the same
@@ -2622,5 +2668,5 @@
 unification of configuration options between config files on disk and
 the options specified on the command line is handled by
-\ippmisc{psModules} functions, as is the contruction of data
+\ippmisc{psModules} functions, as is the construction of data
 structures in memory to represent the astronomical camera based on the
 header information in the input file.  The functions to generate and
@@ -2792,5 +2838,5 @@
 to hang until the job time limit is reached.  These stacks were
 instead processed on the regular IPP cluster, where hosts with
-sufficent memory were available.
+sufficient memory were available.
 
 \subsection{UH Cray Cluster} 
@@ -2820,6 +2866,18 @@
 994,890 runs processed there.
 
-\section{Discussion}
-\label{sec:discussion}
+\section{Conclusion}
+
+Since the Pan-STARRS\,1 telescope first came online in 2007, this
+telescope has obtained 1.43 million exposures with GPC1, amounting to
+a raw data volume of 4.32 petabytes.  The Pan-STARRS Image Processing
+Pipeline has archived and processed these images on-the-fly to produce
+discoveries of transient events and hazardous asteroids in real-time.
+The IPP has been used to perform several re-processings of large
+fractions of the science exposures to produce a well-calibrated data
+release of the $3\pi$ Survey data.  To date, and including repeated
+analysis, the IPP has processed 2.1 million exposures, detecting 900 billion
+sources in those exposures (real and otherwise!).  The Pan-STARRS data
+processing system represents a real example of astronomy data
+processing on the very large scale.
 
 \acknowledgments
