Index: /trunk/doc/design/design.tex
===================================================================
--- /trunk/doc/design/design.tex	(revision 420)
+++ /trunk/doc/design/design.tex	(revision 421)
@@ -1,12 +1,13 @@
-%%% $Id: design.tex,v 1.2 2004-04-09 02:27:09 eugene Exp $
+%%% $Id: design.tex,v 1.3 2004-04-13 04:05:15 price Exp $
 %\documentclass[panstarrs,psreport]{panstarrs}
 \documentclass[panstarrs]{panstarrs}
 
 % basic document variables
-\title{Pan-STARRS Image Processing Pipeline Supplementary Design Requirements}
-\shorttitle{IPP SSDD}
+\title{Pan-STARRS Image Processing Pipeline}
+\subtitle{Supplementary Design Requirements Specification}
+\shorttitle{IPP SDRS}
 \author{Eugene Magnier, Paul Price, Josh Hoblitt}
-\group{Pan-STARRS Algorithm Group}
-\project{Pan-STARRS Image Processing Pipeline}
+\group{\PS{} Algorithm Group}
+\project{\PS{} Image Processing Pipeline}
 \organization{Institute for Astronomy}
 \version{DR}
@@ -39,6 +40,6 @@
 
 This document establishes the design, performance, development, and
-verification requirements for the Pan-STARRS Image Processing Pipeline
-(IPP) for both the full four-telescope Pan-STARRS deployment (PS-4)
+verification requirements for the \PS{} Image Processing Pipeline
+(IPP) for both the full four-telescope \PS{} deployment (PS-4)
 and the initial single-telescope demonstration deployment (PS-1).
 
@@ -49,6 +50,6 @@
 \subsection{Document Overview}
 
-Open Issues and TBDs in this document are marked in bold with
-surrounding square brackets.
+Open Issues and TBDs in this document are marked in bold red type,
+with surrounding square brackets, \tbd{like this}.
 
 \section{Referenced Documents}
@@ -59,5 +60,5 @@
 \hline
 \multicolumn{2}{l}{\bf Internal Documents} \\
-xxx-xxx-xxx  &   Pan-STARRS Telescope Scheduler specification document \\
+xxx-xxx-xxx  &   \PS{} Telescope Scheduler specification document \\
 xxx-xxx-xxx  &   Telescope Control System specification document \\
 xxx-xxx-xxx  &   Summit Pixel Server specification document \\
@@ -66,5 +67,5 @@
 xxx-xxx-xxx  &   Camera Readout specification document \\
 xxx-xxx-xxx  &   PS-1 Design Reference Mission \\
-xxx-xxx-xxx  &   Pan-STARRS C Code Conventions \\
+xxx-xxx-xxx  &   \PS{} C Code Conventions \\
 \hline
 \multicolumn{2}{l}{\bf External Documents} \\
@@ -77,17 +78,17 @@
 \section{System Design Decisions}
 
-Pan-STARRS is a survey telescope system being developed by the
+\PS{} is a survey telescope system being developed by the
 University of Hawaii Institute for Astronomy (IfA), the Maui High
 Performance Computing Center (MHPCC), Science Applications
-International Corporation (SAIC), and \note{Massachusetts Institute of
-Technology (MIT) Lincoln Laboratory}.  The baseline system will
-consist of 4 1.8m telescopes, each with a 1 gigapixel camera capable
-of sustained image rates of 2 per minute.  An single initial test
+International Corporation (SAIC), and Massachusetts Institute of
+Technology (MIT) Lincoln Laboratory.  The baseline system will consist
+of four 1.8m telescopes, each with a 1 gigapixel camera capable of
+sustained image rates of 2 per minute.  An single initial test
 telescope (PS-1) will be constructed on Haleakala and will see first
 light at the beginning of 2006.  The full four-telescope system (PS-4)
 will follow PS-1 by roughly 2 years.
 
-Since Pan-STARRS is a survey project, all data from the telescopes
-will be uniformly analysed by the Pan-STARRS Image Processing Pipeline
+Since \PS{} is a survey project, all data from the telescopes
+will be uniformly analysed by the \PS{} Image Processing Pipeline
 (IPP) and the appropriate resulting data products made available to
 internal and external science analysis systems as they become
@@ -95,6 +96,6 @@
 will consist of detrending and object detection for the individual
 images, combination of multiple overlapping images and further object
-detection, subtraction of a reference (static-sky) image and detectiono
-f residual objects, update of the static sky images, and detailed
+detection, subtraction of a reference (static-sky) image and detection
+of residual objects, update of the static sky images, and detailed
 object analysis of the static sky images.  In addition, the IPP will
 produce improved astrometric and photometric reference catalogs on an
@@ -104,15 +105,16 @@
 object photometry, and reference astrometry and photometry.
 
-The IPP interacts closely with other Pan-STARRS systems responsible
-for other aspects of the Pan-STARRS operation, including the summit
-systems (OATS), the science object database, the Moving/Transient
-Object Pipeline, and potentially other client science pipelines.
-
-The Pan-STARRS Image Processing Pipeline (IPP) consists of a
+The IPP interacts closely with other \PS{} systems responsible
+for other aspects of the \PS{} operation, including the summit
+systems (OATS), the science object database, the Moving Object
+Processing System (MOPS), and potentially other client science
+pipelines.
+
+The \PS{} Image Processing Pipeline (IPP) consists of a
 collection of computer hardware and software organized to perform the
-tasks required to process images from the Pan-STARRS telescopes.  The
+tasks required to process images from the \PS{} telescopes.  The
 primary goal of the IPP is to process the science images from the
-Pan-STARRS telescopes and make the results available to other systems
-within Pan-STARRS.  To achieve this goal, the IPP must also perform
+\PS{} telescopes and make the results available to other systems
+within \PS{}.  To achieve this goal, the IPP must also perform
 other analysis functions to generate the calibrations needed in the
 science image processing and to occasionally use the derived data to
@@ -120,17 +122,22 @@
 
 In order to meet these broad goals, the IPP must have the following
-capabilities.  First, the IPP must have the ability to store a large
-amount of image data, and other derived data products (metadata \&
-extracted objects), to provice access mechanisms to these data
-products (both to the subsystems of the IPP and in some cases to
-external users), and to continuously accept new image data and
-metadata from the telescope system, 2) to execute various analysis
-processes using these data products, 3) to provide the decision-making
-logic needed to guide the data processing, and to automatically launch
-the data processing tasks on an appropriate timescale.  The IPP
-therefore includes subsystems which provide the data storage
+capabilities:
+\begin{itemize}
+\item Store a large amount of image data, and other derived data
+products (metadata and extracted objects);
+\item Provide access mechanisms to these data products (both to the
+subsystems of the IPP and in some cases to external users);
+\item Continuously accept new image data and
+metadata from the telescope system;
+\item Execute various analysis processes using these data products;
+and
+\item Provide the decision-making logic needed to guide the data
+processing, and to automatically launch the data processing tasks on
+an appropriate timescale.
+\end{itemize}
+The IPP therefore includes subsystems which provide the data storage
 framework, the data analysis framework, and the scheduling of the
 analysis processes.  The data storage subsystems also provide
-interface mechanisms to the external Pan-STARRS systems.
+interface mechanisms to the external \PS{} systems.
 
 The IPP architecture can be viewed in several possible ways.  We first
@@ -147,38 +154,39 @@
 \subsubsection{Architectural Components}
 
-The IPP is organised into several different software elements, listed
+The IPP is organised into several different architectural components,
 as follows:
 
 \begin{enumerate}
-\item Pixel Server
-\item Object Database
-\item Metadata Database
-\item Analysis Pipelines
-\item Controller
-\item Scheduler
+\item IPP Pixel Server (IPS) --- a respository for all image pixel
+data, including the raw images from the telescope, the master
+calibration images, the reference static-sky images, and any temporary
+image data products produced by the IPP.
+\item IPP Object Database (IOD) --- a facility to store all of the
+information about astronomical objects, including individual
+measurements of objects on the images, the summary information about
+those objects, and reference object data\footnote{Note that this is
+(possibly) a separate entity from the object database being developed
+by SAIC.}.
+\item IPP Metadata Database (IMD) --- a storage element for all data
+which is neither image pixel data or astronomical object data.
+\item Analysis Pipelines --- all of the top-level analysis processes
+which are performed on images or collections of object data.
+\item Controller --- a system which manages the process of executing
+in parallel analysis pipelines on specific datasets on the cluster of
+computers.
+\item Scheduler --- a system which evaluates the current state of data
+in the various repositories and makes decisions about which analysis
+processes should be executed at any given time.
 \end{enumerate}
 
 The relationship between these software elements is shown in
 Figure~\ref{overview}.  This figure also shows the interactions
-between the IPP and other Pan-STARRS systems.  The Pixel Server is a
-respository for all image pixel data, including the raw images from
-the telescope, the master calibration images, the reference static-sky
-images, and any temporary image data products produced by the IPP.
-The Object Database is a facility to store all of the information
-about astronomical objects, including individual measurements of
-objects on the images, the summary information about those objects,
-and reference object data.  The Metadata Database is a storage element
-for all data which is neither image pixel data or astronomical object
-data.  The analysis pipelines are all of the top-level analysis
-processes which are performed on images or collections of object data.
-The Controller is a system which manages the process of executing in
-parallel analysis pipelines on specific datasets on the cluster of
-computers.  The Scheduler is a system which evaluates the current
-state of data in the various repositories and makes decisions about
-which analysis processes should be executed at any given time.  
+between the IPP and other \PS{} systems.
+
+The IPP team will develop and have responsibility for these systems.
 
 \begin{figure}
 \begin{center}
-\resizebox{8cm}{!}{\includegraphics{pics/overview.ps}}
+\resizebox{8cm}{!}{\includegraphics{pics/overview}}
 \caption{ \label{overview} IPP System Overview}
 \end{center}
@@ -194,7 +202,7 @@
 OTA in one image does not depend on the results from another OTA.  We
 define the analysis pipelines to be the largest complete analysis task
-which may be performed on a single data item.  {\bf drop the word
-'pipeline' and use something else?}.  The data analysis pipelines are
-divided into three categories, and further subdivided as follows:
+which may be performed on a single data item.  The data analysis
+pipelines are divided into three categories, and further subdivided as
+follows:
 
 \begin{enumerate}
@@ -223,14 +231,12 @@
 controller.  The thick lines represent the flow of pixel data, the
 thin lines represent the flow of metadata and object data, and the
-grey lines represent the flow of commands.  {\bf All subsystem
-interactions, except that between the scheduler and controller, are in
-the form of updates to and queries from the databases}.  The hatched
-systems represent external PanSTARRS systems (OATS, the Sky Server,
-the SAIC Object Database, the Moving/Transient Object Pipeline, and
-other Client Science Pipelines.
+grey lines represent the flow of commands.  The hatched systems
+represent external \PS{} systems (OATS, the Sky Server, the SAIC
+Object Database, the Moving Object Processing System, and other Client
+Science Pipelines).
 
 \begin{figure}
 \begin{center}
-\resizebox{8cm}{!}{\includegraphics{pics/pipelines.ps}}
+\resizebox{8cm}{!}{\includegraphics{pics/pipelines}}
 \caption{ \label{pipelines} IPP System Overview}
 \end{center}
@@ -246,10 +252,10 @@
 databases.  This last aspect is largely theoretical until we have
 defined the details of these databases; it may be more appropriate
-depending on the eventual solutions to distribution these database
+depending on the eventual solutions to distribute these database
 elements across the OTA and Static Sky subclusters.
 
 \begin{figure}
 \begin{center}
-\resizebox{8cm}{!}{\includegraphics{pics/hardware.ps}}
+\resizebox{8cm}{!}{\includegraphics{pics/hardware}}
 \caption{ \label{hardware} IPP Hardware Organization}
 \end{center}
@@ -258,27 +264,39 @@
 \subsection{Software Hierarchy}
 
-\subsubsection{External Data Libraries}
-
-\subsubsection{Pan-STARRS Data Library}
-
 In order to facilitate testing and development, and to encourage
 flexibility, the IPP will be built in a layered fashion.  The lowest
 level functions will be written in C and collected together into a
-Pan-STARRS library.  These library functions can be used to write more
+\PS{} library.  These library functions will be used to write more
 complex modules.  The modules will be written in C but will make use
 of the SWIG tool to make their functionality available within other
 frameworks.  In particular, the modules can be tied together with a
-simple framework ('the engine') or with detailed flow-control through
-the use of a high-level language such as Perl, Python, or TCL.  For
+simple framework (an `engine') or with detailed flow-control through
+the use of a high-level language such as Perl, Python, or Tcl.  For
 the high-level functions in the operational system, the IPP will make
 use of \tbd{Python} as the scripting language to tie the modules
-together.  Note that a subset of the library functions will be
-provided with SWIG interfaces as well to allow for their use the in
-creation of the top-level functions.
-
-The Pan-STARRS Data Library consists of C structures describing the
-basic data types needed by the IPP and C functions which perform the
-basic data manipulation operations.  The library is organized into NN
-topics.
+together.
+
+This approach satisfies the requirement that complicated low-level
+analysis steps run fast, while preserving flexibility for coding the
+high-level wrappers for which the speed requirements are not so
+stringent.
+
+\subsubsection{External Libraries}
+
+\PS{} will employ several external libraries to save duplicating
+functionality that is already available.  These external libraries
+will be wrapped by the \PS{} Library, insulating the project from the
+implementation details of the external libraries.  Examples of the
+external libraries are FFTW and SLALib.
+
+\subsubsection{\PS{} Library}
+
+The \PS{} Library will consist of C structures describing the basic
+data types needed by the IPP and C functions which perform the basic
+data manipulation operations.  Note that a subset of the library
+functions will be provided with SWIG interfaces as well to allow for
+their use in the creation of the processing stages.  Examples of the
+\PS{} Library are fourier transforms and transforming between pixel
+and celestial coordinates.
 
 \subsubsection{Modules}
@@ -286,14 +304,34 @@
 The IPP analysis tasks are broken down into modules which represent
 specific functional operations.  The modules will be written in C
-using the Pan-STARRS Data Library functions and will be grouped into a
-Pan-STARRS Module Library.  The modules will be provided with SWIG
-interfaces to all for their use in top-level functions.
+using the \PS{} Library functions and will be grouped into a \PS{}
+Module Library.  The modules will be provided with SWIG interfaces to
+all public APIs for their use in processing stages.  Examples of modules
+are overscan subtraction and image combination.
 
 \subsubsection{Stages}
 
-The major IPP tasks are organized into stages.  Each stage represents
-a collection of complex operations performed on a single data entity.
-Each stage therefore represents the maximum amount of effort which can
-be performed in serial without interaction between parallel threads.  
+The major IPP tasks are organized into stages, which consist of
+multiple modules.  Each stage represents a collection of complex
+operations performed on a single data entity.  Each stage therefore
+represents the maximum amount of effort which can be performed in
+serial without interaction between parallel threads.  The stages will
+be written in \tbd{Python}, linking the modules together.  Examples of
+stages are Phase 2 (detrend images) and Phase 4 (combine images from
+multiple telescopes and search for transients).
+
+\subsubsection{Controllers}
+
+The stages are parallelized by a controller, which initiates the
+stages on separate machines and monitors their progress.  An example
+of the controller functionality is ``Run the phase 2 processing on
+exposure number 1234''.
+
+\subsubsection{Scheduler}
+
+The scheduler is responsible for interacting with \PS{} systems
+external to the IPP, and for initiating the reduction appropriate for
+images as they are received.  An example of the scheduler
+functionality is ``I've just received exposure number 1234; run phase
+1--4 controllers on these''.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -316,17 +354,17 @@
 they are needed, up to the lifetime of the project.  In order to
 achieve the I/O requirements, the IPS may maintain the pixel data
-distributed across the processor nodes in an organized fashion, ie
+distributed across the processor nodes in an organized fashion, i.e.\
 associating specific machines with specific OTAs.  The IPS interacts
-with the IPP Internal Database to allow other systems or subsystems to
+with the IPP Metadata Database to allow other systems or subsystems to
 identify the available images meeting specified criteria.  IPS
-specifications are described in the IPS subsystem specification. 
-
-In addition the IPS is responsible for acquiring new image data and
-meta-data from the Summit Pixel Server and making it available for
-processing by the IPP System.  
+specifications are described in the IPS subsystem specification.
+
+In addition to storing the pixel data, the IPS is responsible for
+acquiring new image data and metadata from the Summit Pixel Server and
+making it available for processing by the IPP System.
 
 \paragraph{Pixel Server Components}
 
-The Pixel Server consists of the following components:
+The IPP Pixel Server consists of the following components:
 
 \begin{enumerate}
@@ -343,56 +381,65 @@
 The IPP Pixel Data Scheduler coordinates the movement of image data
 onto {\em local} storage for processing by the IPP System and executes
-batch image data management tasks.
-
-The IPP Pixel Data Scheduler has four basic modes of operation.
+batch image data management tasks.  By ``local storage'' is meant
+storage accessible from a particular local machine (i.e.\ either on a
+disk physically connected to the machine, or a disk mounted over the
+network).
+
+The IPP Pixel Data Scheduler has four basic modes of operation:
 
 \begin{itemize}
-\item The Summit Pixel Server sends a new data available message to the
-IPP-PDS.  The IPP-PDS generates a {\em retrieve data} task which is passed
-through 0 or more registered filters.  The task is then sent to the IPP Controller.
-\item The IPP-PDS receives a clean stale data message.  \tbd{The source of
-which is TBD}.  A list of {\em delete data} tasks are generated
-which is passed to the IPP Pixel Data Locality Optimizer for assignment
-to specific the data storage locations.  The list of tasks is then sent
-to the IPP Controller.
-\item The IPP-PDS receives a data replication message.  \tbd{The source of
-which is TDB}.  A list of {\em retrieve data} tasks are generated to
-copy the data.  The list of tasks is then sent to the IPP Controller.
-\item The IPP-PDS receives a move data message. \tbd{The source of
-which is TDB}.  A list of {\em retrieve data} tasks are generated to copy the 
-data to it's new destination.  The list of tasks is then sent to the IPP
-Controller.l  Upon receiving task completed notification from the IPP
-Controller a list of {\em delete data} tasks are generated to remove the data
-from it's original storage location.  This list of tasks is then sent to the
-IPP Controller.
+\item Copy external data: The IPP-PDS generates {\em retrieve data}
+  tasks which are executed on nodes specified by the IPP-DLO.  This
+  mode will be used frequently to copy data from the Summit Pixel
+  Server to the IPP nodes for processing.
+\item Delete data: The IPP-PDS looks up the location of the data in
+  the IPP Pixel Data Database and generates {\em delete data} tasks
+  which are executed on the appropriate nodes.  This mode will be used
+  on a regular basis to clean old data that is no longer required.
+\item Replicate data: The IPP-PDS generates {\em retrieve data} tasks
+  which are executed on nodes specified either by the ``replicate
+  data'' command, or by the IPP-DLO.  This mode differs from the
+  ``copy external data'' mode in that it copies data already within
+  the IPP-PDS.  This mode will be used to backup and rearrange data.
+\item Move data: the IPP-PDS executes a replication followed by a
+  deletion.  This mode will be used to reorganise the storage.
 \end{itemize}
 
+It is not intended that the IPP-PDS will be used by the nodes in the
+course of processing --- it is only for bulk data management.  ``Copy
+external data'' mode will be used frequently to retrieve data from the
+Summit Pixel Server.  ``Delete data'' mode will be used on a regular
+basis to flush the system of stale files.  It is expected that the
+other modes will be used only occassionally, and initiated by a human
+operator.
+
+
 \subparagraph{IPP Pixel Data Locality Optimizer (IPP-PDLO)}
 
-The IPP Pixel Data Locality Optimizer is a data task filter that registers with
-the IPP Pixel Data Scheduler.  Data tasks generated by the IPP Pixel Data
-Scheduler are passed through the IPP Pixel Data Locality Optimizer which may
-assign tasks to specific nodes.  This component is a merely a plug-in and maybe
-bypassed depending on the operating mode of the IPP Pixel Data Scheduler.
+The IPP Pixel Data Locality Optimizer is a data task filter.  Data
+tasks generated by the IPP Pixel Data Scheduler are passed through the
+IPP Pixel Data Locality Optimizer which may assign tasks to specific
+nodes.  This component is a merely a plug-in and may be bypassed
+depending upon the operating mode of the IPP Pixel Data Scheduler.
 
 \subparagraph{IPP Pixel Data Database (IPP-PDD)}
 
-The IPP Pixel Data Database contains image data locations and the associated
-meta-data.  
+The IPP Pixel Data Database contains image data locations \tbd{and the
+associated metadata}.
 
 The IPP-PDD will contain at least:
 
 \begin{itemize}
-\item The location of image data and it's associated meta-data that is
+\item The location of image data and its associated metadata that is
 available for retrieval from the Summit Pixel Server.
-\item The location of image data and it's associated meta-data that is available
-for processing within the IPP System.
-\item The location of calibration data and it's associated meta-data for
+\item The location of image data and its associated metadata that is
+yet to be processed by the IPP System.
+\item The location of calibration data and its associated metadata for
 processing within the IPP System.
-\item The location of reduced image data and it's associated meta-data as
+\item The location of reduced image data and its associated metadata as
 generated by the IPP System.
-\item The location of difference image data and it's associated meta-data as
+\item The location of difference image data and its associated metadata as
 generated by the IPP System.
-\item The location of stacked image data and it's associated meta-data as
+\item The location of stacked image data and its associated metadata as
 generated by the IPP System.
 \item A history of data management commands and actions.
@@ -401,27 +448,26 @@
 \subparagraph{IPP Pixel Data Retrieval Agent (IPP-PDRA)}
 
-The IPP Pixel Data Retrieval Agent acquires image data from a specified location,
-possibly the Summit Pixel Server(s), and stores it at a specified location.
-The IPP-PDRA attempts to be independent of the underlying storage medium by
-using the IPP Pixel Data I/O Library.
-
-\subparagraph{IPP Pixel Data Query Library (IPP-PDQL)}
-
-The IPP Pixel Data Query Library provides an interface to the IPP Pixel Data
-Database while hiding the implementation details (ie. the SQL queries).
-
-It will be able to:
-
+The IPP Pixel Data Retrieval Agent acquires image data from a
+specified location, possibly the Summit Pixel Server(s), and stores it
+at a specified location.  The IPP-PDRA is independent of the
+underlying storage medium by using the IPP Pixel Data I/O Library.
+
+
+\subparagraph{IPP Pixel Data I/O Library (IPP-PDIOL)}
+
+The PDIOL is the workhorse of the Pixel Server system.  It is a
+library for retrieving files from and storing files to Uniform
+Resource Identifiers (URIs), which can be used on the nodes to access
+the pixel data.  It will be able to:
 \begin{itemize}
-\item Locate new and reduced data for a sky cell.
-\item Locale the latest calibration data for sky cell.
-\item Add the storage location and meta-data of new data.
-\item Update the storage location and/or meta-data of any data.
-\item Remove the storage location of data and meta-data that has been deleted.
+\item Locate new and reduced data for an exposure.
+\item Locate the appropriate calibration data for an exposure.
+\item Add the storage location and metadata of new data.
+\item Update the storage location and/or metadata of any data.
+\item Remove the storage location of data and metadata that has been
+deleted.
 \end{itemize}
 
-\subparagraph{IPP Pixel Data I/O Library (IPP-PDIOL)}
-
-A library for retrieving files from and storing files to URIs.
+
 
 \paragraph{Pixel Data Flow}
@@ -430,19 +476,16 @@
 
 \begin{enumerate}
-\item The Summit Pixel Server sends a new data notification to the
+\item The Summit Pixel Server sends a ``new data notification'' to the
 IPP Pixel Data Data Scheduler.
-\item The IPP Pixel Data Data Scheduler generates a {\em retrieve data} task
-which is passed to the IPP Pixel Data Locality Optimizer.
-\item The IPP Pixel Data Locality Optimizer possibly assigns the task
-to a specific node or group of nodes and passes it on to the IPP Controller.
-\item The IPP Controller passes the task to a \tbd{IPP Node Agent}.
-\item The \tbd{IPP Node Agent} spawns a IPP Pixel Data Retrieval Agent
-and passes it the task.
-\item The IPP Pixel Data Retrieval Agent downloads the image data from the
-Summit Pixel Server.
-\item The IPP Pixel Data Retrieval Agent reports successful task completion
-to the \tbd{IPP Node Agent}.
-\item The \tbd{IPP Node Agent} reports the finished task to the IPP Controller.
-\item The IPP Controller reports the finished task to the IPP Pixel Data Scheduler.
+\item The IPP Pixel Data Data Scheduler generates a {\em retrieve
+data} task which is filtered through the IPP Pixel Data Locality
+Optimizer, which possibly assigns the task to a specific node or group
+of nodes.
+\item The IPP Pixel Data Scheduler farms out the various copy tasks to
+the nodes, which spawn IPP Pixel Data Retrieval Agents.
+\item The IPP Pixel Data Retrieval Agents downloads the image data
+from the Summit Pixel Server to the disk physically mounted on the
+node.
+\item The node reports the finished task to the IPP Pixel Data Scheduler.
 \item The IPP Pixel Data Scheduler updates the IPP Pixel Data Database to
 the new storage location.
@@ -517,16 +560,15 @@
 additional analysis.  The Metadata Database may potentially be used in
 close coupling with the analysis pipelines to store temporary data
-either within stages of the analysis or between pipeline stages.  In
-this scenario, the analysis pipeline will interact directly with the
-database.  However, database latency may make this scenario
-impractical, in which case the database may be used for long-term
-storage only.  In this scenario, the data produced by analysis
-pipelines which is destined for the Metadata Database may be collected
-and inserted by a separate, dedicated process or analysis pipeline
-collection of processes.
+either within or between stages of the analysis.  In this scenario,
+the analysis pipeline will interact directly with the database.
+However, database latency may make this scenario impractical, in which
+case the database may be used for long-term storage only.  In this
+scenario, the data produced by analysis pipelines which is destined
+for the Metadata Database may be collected and inserted by a separate,
+dedicated process or analysis pipeline collection of processes.
 
 \paragraph{Metadata Tables}
 
-Table NN lists the Metadata tables identified for the Metadata
+Table \tbd{NN} lists the Metadata tables identified for the Metadata
 Database.
 
@@ -562,5 +604,5 @@
 \paragraph{Metadata Table Contents}
 
-Tables NN -- NN list the basic contents of each of the Metadata tables
+Tables \tbd{NN} -- \tbd{NN} list the basic contents of each of the Metadata tables
 listed above.
 
@@ -938,18 +980,18 @@
 \subsubsection{Controller}
 
-The IPP Controller is responsible for executing the connecting the
-low-level functions together to define the various processing
-subsystems.  The Controller manages the parallel processing of these
-subsystems in the IPP computer hardware environment and reports the
-processing status to the IID.  The Controller must be able to manage
-more than a single processing thread to make maximum use of available
-processor resources.  Some analysis jobs, such as operations on the
-OTAs, must be allocated preferentially to specified processors, while
-others must be distributed to the available machines in the cluster.
+The IPP Controller is responsible for connecting the low-level modules
+together to define the various processing subsystems.  The Controller
+manages the parallel processing of these subsystems in the IPP
+computer hardware environment and reports the processing status to the
+IMD.  The Controller must be able to manage more than a single
+processing thread to make maximum use of available processor
+resources.  Some analysis jobs, such as operations on the OTAs, must
+be allocated preferentially to specified processors, while others must
+be distributed to the available machines in the cluster.
 
 \paragraph{Components}
 
-The Controller consists of N components: the Controller daemon, the
-remote clients, and the user clients.  
+The Controller consists of the following components: the Controller
+daemon, the remote clients, and the user clients.
 
 The Controller daemon maintains a table of processing nodes available
@@ -978,17 +1020,19 @@
 The commands include:
 
-{\bf \em report status} return the state of the client (idle, busy,
-done), the state of the current job (none, busy, crash, done), and the
-exit status of the current job (none, 0-256).  The three states of the
-client indicate that the client has no current job (idle), that it has
-a job which is still running (busy), and that it has a job which has
-completed.  The job states indicate the there is no current job
-(none), that the current job is running (busy), that the current job
-has crashed (crash), and that the current job has exited gracefully
-(done).  The exit state is the exit state reported by the job (0-256
-with 0 indicating a successful completion) or is an indication that
-there is no current job (none).
-
-{\bf \em report stdout} Send and flush the current stdout buffer.  The
+{\bf \em report status}: Return the state of the client (idle, busy,
+done), the state of the current job\footnote{Note that a job is
+considered ``current'' until it is cleared with {\em clear job} ---
+even if it has crashed or completed.} (`none', `busy', `crash',
+`done'), and the exit status of the current job (`none', 0--256).  The
+three states of the client indicate that the client has no current job
+(`idle'), that it has a job which is still running (`busy'), and that
+it has a job which has completed.  The job states indicate the there
+is no current job (`none'), that the current job is running (`busy'),
+that the current job has crashed (`crash'), and that the current job
+has exited gracefully (`done').  The exit state is the exit state
+reported by the job (0--256 with 0 indicating a successful completion)
+or is an indication that there is no current job (`none').
+
+{\bf \em report stdout}: Send and flush the current stdout buffer.  The
 remote client will return the complete contents of the stdout buffer
 via a buffered write and flush the buffer when it is finished.  The
@@ -997,15 +1041,15 @@
 daemon must accept all of the buffer output.
 
-{\bf \em report stderr} Identical to 'report stdout' for stderr.  
-
-{\bf \em kill job} remote client should send a kill signal to the
+{\bf \em report stderr}: Identical to `report stdout' for stderr.  
+
+{\bf \em kill job}: remote client should send a kill signal to the
 current job.  When the job has exited, the remote client should set
-the job status to crash and the client status to done.
-
-{\bf \em clear job} The remote client should set the current job state
-to 'none' and the client state to 'idle'.  If a job is currently
+the job status to `crash' and the client status to `done'.
+
+{\bf \em clear job}: The remote client should set the current job state
+to `none' and the client state to `idle'.  If a job is currently
 running, it should be killed before the job is cleared.
 
-{\bf \em start job [command]} execute the given command.  The command
+{\bf \em start job [command]}: execute the given command.  The command
 should be a standard unix command without command line redirection or
 backgrounding.
@@ -1041,5 +1085,5 @@
 and for initiating the various processing systems, executed by the IPP
 Controller, based on the state of the survey as reflected by the IPP
-Internal Database (IID).  The Scheduler must send calibration data
+Metadata Database (IMD).  The Scheduler must send calibration data
 requests to the PTS, including required flat-field images, flat-field
 correction observations, or other specialized observations needed to
@@ -1048,17 +1092,7 @@
 timely manner given the capabilities of the science pipelines.
 
-The scheduler is a subsystem which defines the tasks that the pipeline
-needs to perform at any given time.  The scheduler takes input
-information which describes the collection of all tasks which may need
-to be performed, along with information about their requirements in
-terms of specific data (images / entries in database tables).  The
-scheduler decides which tasks to perform at any moment based on the
-current state of the pixel and metadata databases, by confronting the
-task descriptions and task requirements with the existence of data in
-the databases.
-
 \tbd{how are the schedules defined? how are dependencies between jobs
-  defined? scheduler must communicate with the controller (as a user
-  client) to send new jobs}.
+defined? scheduler must communicate with the controller (as a user
+client) to send new jobs}.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -1072,13 +1106,13 @@
 The IPP science image pipelines perform analyses on the night-sky
 science images to extract the science data from these images.  These
-consist of: Phase 0, the night preparation stage; Phase 1, the image
-processing preparation stage; Phase 2, the image reduction stage;
-Phase 3, the exposure analysis stage; and Phase 4, the image
-combination stage.  These pipelines must process the images in a
-timely manner so that the incoming data stream will not overload the
-IPS.  The decision to execute a specific pipeline for a specific
-dataset is made by the Scheduler, which sends the infomation to the
-Controller.  The Controller executes the pipeline for the data on an
-appropriate machine and monitors the success or failure of the job.
+consist of: Phase 1, the image processing preparation stage; Phase 2,
+the image reduction stage; Phase 3, the exposure analysis stage; and
+Phase 4, the image combination stage.  These pipelines must process
+the images in a timely manner so that the incoming data stream will
+not overload the IPS.  The decision to execute a specific pipeline for
+a specific dataset is made by the Scheduler, which sends the
+infomation to the Controller.  The Controller executes the pipeline
+for the data on an appropriate machine and monitors the success or
+failure of the job.
 
 \paragraph{Calibration Image Pipelines}
@@ -1095,5 +1129,5 @@
 \paragraph{Reference Catalog Pipelines}
 
-The IPP reference catalog pipelines use the data in the IPP Internal
+The IPP reference catalog pipelines use the data in the IPP Metadata
 Database and the IPP Object Database to determined improved
 astrometric and photometric calibration references.
@@ -1126,14 +1160,14 @@
 used by the later stages to initiate the analyses.  
 
-The phase 1 analysis is performed on a FPA basis to ensure that enough
-reference stars are available for the astrometry calculation.  Phase 1
-cannot be usefully calculated on the basis of a major frame since the
-telescope positions are independent; no additional information is
-available by combining stars from different FPAs.  This analysis does
-not restrict the definition of a major frame in any way.
-
-\note{Phase 1 command: P1 (exposure)}
-
-\note{Megacam: P1 654321o}
+The phase 1 analysis is performed on an FPA basis to ensure that
+enough reference stars are available for the astrometry calculation.
+Phase 1 cannot be usefully calculated on the basis of a major frame
+since the telescope positions are independent; no additional
+information is available by combining stars from different FPAs.  This
+analysis does not restrict the definition of a major frame in any way.
+
+\tbd{Phase 1 command: P1 (exposure)}
+
+\tbd{Megacam: P1 654321o}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -1151,5 +1185,5 @@
 \begin{figure}
 \begin{center}
-\resizebox{8cm}{!}{\includegraphics{pics/phase2.ps}}
+\resizebox{8cm}{!}{\includegraphics{pics/phase2}}
 \caption{ \label{phase2} Phase 2 dataflow}
 \end{center}
@@ -1158,5 +1192,5 @@
 \paragraph{Phase 2 Concept}
 
-Phase~2 processing within the Pan-STARRS image processing pipeline is
+Phase~2 processing within the \PS{} image processing pipeline is
 the de-trend stage, where the images from the detector are processed
 to remove instrumental signatures.  Phase~2 processing is purely serial,
@@ -1167,32 +1201,26 @@
 the guide stars and initial masking of ghost reflections.
 
-Phase~2 consists of the following tasks:
+Phase~2 consists of the following modules:
 \begin{enumerate}
 \item Form OT kernel;
 \item Convolve de-trend images with the OT kernel;
-\item bias / dark / Overscan subtraction;
-\item Trim;
+\item Mask bad pixels
+\item Mask diffraction spikes and optical ghosts;
+\item Bias/dark/overscan subtraction;
+\item Trim overscan;
 \item Non-linearity correction;
 \item Flat-field;
 \item Subtract sky;
 \item Identify CRs by morphology;
-\item Find objects in the image; and
+\item Determine PSF model;
+\item Find and photometer objects in the image;
+\item Improved astrometry; and
 \item Bright object postage stamps.
-\item {\em from old version:}
-\item mask bad pixels
-\item remove diffraction spikes
-\item remove ghosts
-\item remove cosmic rays
-\item estimate foreground 
-\item subtract foreground
-\item extract objects, photometry
-\item determine PSF model
-\item improved astrometry based on comparison with references.
-\end{enumerate}
-These tasks are each explained below.
+\end{enumerate}
+These modules are each explained below.
 
 \paragraph{Form OT Kernel}
 
-The first task for Phase~2 is to form the OT kernel from the image
+The first module for Phase~2 is to form the OT kernel from the image
 metadata of pixel shifts made during the exposure.  This involves
 decoding the metadata and converting it to a data type that can be
@@ -1202,9 +1230,9 @@
 \paragraph{Convolve de-trend images}
 
-This task convolves the de-trend images with the OT convolution kernel
+This module convolves the de-trend images with the OT convolution kernel
 so that they can be used to de-trend the object image.  The inputs
 are:
 \begin{enumerate}
-\item The OT convolution kernel --- from the previous task;
+\item The OT convolution kernel --- from the previous module;
 \item The appropriate dark frame --- from the IPP Pixel Server;
 \item The appropriate flat-field --- from the IPP Pixel Server;
@@ -1213,8 +1241,8 @@
 \end{enumerate}
 
-The task convolves each of the dark frame, flat-field, and the fringe
+The module convolves each of the dark frame, flat-field, and the fringe
 frame(s) by the OT convolution kernel.  Specific flags in the static
 bad pixel mask are grown by the outline of the OT convolution kernel
-(see Appendix \ref{ap:masks}).  The output results are:
+(see Section \ref{ap:masks}).  The output results are:
 \begin{enumerate}
 \item The convolved flat-field;
@@ -1222,14 +1250,14 @@
 \item The updated pixel mask.
 \end{enumerate}
-Each of these will be used for a later task.
+Each of these will be used for a later module.
 
 
 \paragraph{Overscan Subtraction}
 
-This task corrects the object exposures for the electronic pedestal
+This module corrects the object exposures for the electronic pedestal
 introduced by the readout electronics.  The inputs are:
 \begin{enumerate}
 \item The object image --- from the IPP Pixel Server;
-\item The pixel mask --- from the previous task;
+\item The pixel mask --- from the previous module;
 \item The overscan and physical detector regions --- from the
 Metadata; and
@@ -1242,21 +1270,21 @@
 Overscan rows having a standard deviation which exceeds a threshold of
 twice (configurable) the detector read noise should be masked.  Pixels
-saturated in the A/D converter should also be masked, and these regions
-grown by an additional pixel.  The output is:
+saturated in the A/D converter should also be masked, and these
+regions grown by an additional pixel to counter CCD ``blooming''.  The
+output is:
 \begin{enumerate}
 \item The overscan-subtracted object image; and
 \item The updated pixel mask.
 \end{enumerate}
-These will be used for a subsequent task.
+These will be used for a subsequent module.
 
 \paragraph{Trim}
 
-This task trims the object image and each of the calibration frames to
+This module trims the object image and each of the calibration frames to
 remove the outer edge which was affected by the OT during the
-exposure.  The inputs, each from previous tasks, are:
+exposure.  The inputs, each from previous modules, are:
 \begin{enumerate}
 \item The overscan-subtracted object image;
 \item The corresponding pixel mask;
-\item The convolved dark frame;
 \item The convolved flat-field;
 \item The convolved fringe frame(s); and
@@ -1264,27 +1292,27 @@
 \end{enumerate}
 
-Each of the input frames (object image, dark frame, flat-field, fringe
-frame(s) and pixel mask) are trimmed by the extent of the OT
-convolution kernel in each direction ($+x$, $-x$, $+y$, $-y$).  The
-outputs are trimmed images for each of the input images, which will be
-used in later tasks.
+Each of the input frames (object image, flat-field, fringe frame(s)
+and pixel mask) are trimmed by the extent of the OT convolution kernel
+in each direction ($+x$, $-x$, $+y$, $-y$).  The outputs are trimmed
+images for each of the input images, which will be used in later
+modules.
 
 \paragraph{Non-Linearity Correction}
 
-This task corrects images for non-linearity in the detector.  The
+This module corrects images for non-linearity in the detector.  The
 inputs are:
 \begin{enumerate}
-\item The trimmed object image --- from a previous task; and
+\item The trimmed object image --- from a previous module; and
 \item The detector non-linearity correction coefficient(s) --- from
 the Metadata.
 \end{enumerate}
 
-The task corrects the flux in each pixel for non-linearity by applying
+The module corrects the flux in each pixel for non-linearity by applying
 a polynomial correction, with the specified coefficients.  The output
-is the corrected object image, which is used for a later task.
+is the corrected object image, which is used for a later module.
 
 \paragraph{Flat field}
 
-This task corrects the object image for variations in sensitivity over
+This module corrects the object image for variations in sensitivity over
 the image.  The inputs are:
 \begin{enumerate}
@@ -1293,7 +1321,7 @@
 \item The convolved, trimmed flat-field.
 \end{enumerate}
-Each of these comes from a previous task.
-
-The task divides the object image by the flat-field, masking pixels
+Each of these comes from a previous module.
+
+The module divides the object image by the flat-field, masking pixels
 that are non-positive in the flat-field.  The outputs are:
 \begin{enumerate}
@@ -1301,17 +1329,17 @@
 \item The updated pixel mask.
 \end{enumerate}
-Both of these will be used in later tasks.
+Both of these will be used in later modules.
 
 \paragraph{Subtract sky}
 
-This task subtracts the sky background from the object image.  The
+This module subtracts the sky background from the object image.  The
 inputs are:
 \begin{enumerate}
-\item The object image --- from the previous task;
+\item The object image --- from the previous module;
 \item The list of objects on the image --- from the object database; and
-\item The convolved, trimmed fringe frame(s) --- from a previous task.
-\end{enumerate}
-
-The task masks (though {\em not} in the ``official'' pixel mask) all
+\item The convolved, trimmed fringe frame(s) --- from a previous module.
+\end{enumerate}
+
+The module masks (though {\em not} in the ``official'' pixel mask) all
 objects on the image using the astrometric solution from the
 boresight, and fits for the sky background, consisting of a polynomial
@@ -1320,11 +1348,10 @@
 is too high to reliably fit the sky background, the background
 solution from an exposure close in time and airmass to the current
-object image.  The output is the sky-subtracted object image, which is
-sent to the IPP pixel server for use in Phase~3, and also used for the
-next task.
+object image is used.  The output is the sky-subtracted object image,
+which is used for the next module.
 
 \paragraph{Identify CRs by morphology}
 
-This task identifies cosmic rays (or other hot pixels missed in the
+This module identifies cosmic rays (or other hot pixels missed in the
 static bad pixel mask) on the basis of their morphology.  The inputs
 are:
@@ -1333,24 +1360,25 @@
 \item The corresponding pixel mask.
 \end{enumerate}
-Both of these come from a previous task.
-
-The task identifies CRs, the pixels of which are masked in the pixel
+Both of these come from a previous module.
+
+The module identifies CRs, the pixels of which are masked in the pixel
 mask.  The pixels flagged as CRs are then grown by an additional pixel
-in each direction.  The output is the updated pixel mask, which is
-sent to the IPP pixel server for use in Phase~3, and is also used for
-the next task.
+in each direction.  Masked pixels are interpolated over.  The outputs
+are the updated pixel mask, which is sent to the IPP pixel server for
+use in Phase~3, and is also used for the next module; and the object image,
+which is sent to the IPP Pixel Server.
 
 \paragraph{Find objects}
 
-This task finds objects on the object image.  The inputs are:
+This module finds objects on the object image.  The inputs are:
 \begin{enumerate}
 \item The sky-subtracted object image; and
 \item The corresponding pixel mask.
 \end{enumerate}
-Both of these come from a previous task.
-
-The task identifies objects on the image, which will be later used to
+Both of these come from a previous module.
+
+The module identifies objects on the image, which will be later used to
 register images from different focal planes.  The output is the
-catalogue of objects (see Appendix~\ref{ap:catalogues}) identified on
+catalog of objects (see Appendix~\ref{ap:catalogs}) identified on
 the image, which is sent to the metadata database, associated with the
 object image.
@@ -1358,14 +1386,14 @@
 \paragraph{Bright object postage stamps}
 
-This task saves postage stamps of bright objects, so that extra care
+This module saves postage stamps of bright objects, so that extra care
 with regard to astrometry and photometry can be taken with them at a
-later stage.  The inputs, each from a previous task, are:
+later stage.  The inputs, each from a previous module, are:
 \begin{enumerate}
 \item The sky-subtracted object image;
 \item The corresponding pixel mask; and
-\item The catalogue of objects.
-\end{enumerate}
-
-The task makes postage stamps of all objects brighter than a given
+\item The catalog of objects.
+\end{enumerate}
+
+The module makes postage stamps of all objects brighter than a given
 instrumental magnitude, along with corresponding pixel masks.  The
 outputs are these postage stamps and pixel masks, which are sent to
@@ -1385,6 +1413,5 @@
 detrend images;
 \item Exposure time --- for the photometric calibration;
-\item Detector gain --- for calculating photometric errors and
-determining the quality of the overscan;
+\item Detector gain --- for calculating photometric errors; and
 \item Detector read noise --- for calculating photometric errors and
 determining the quality of the overscan;
@@ -1395,5 +1422,5 @@
 
 This section describes the requirements on Bad Pixel Masks (BPMs).
-These will consist in of bit masks for each pixel.  For Phase 2, flags
+These will consist of bit masks for each pixel.  For Phase 2, flags
 are required for at least each of the following pixel attributes:
 \begin{enumerate}
@@ -1412,8 +1439,8 @@
 affect the flux in neighbouring pixels
 
-\paragraph{Object Catalogues}
-\label{ap:catalogues}
-
-Object catalogues from Phase 2 shall consist of at least the
+\paragraph{Object Catalogs}
+\label{ap:catalogs}
+
+Object catalogs from Phase 2 shall consist of at least the
 following elements for each object:
 \begin{enumerate}
@@ -1426,10 +1453,10 @@
 \end{enumerate}
 
-Though further details may be required for catalogues in Phase~4,
-the above details are minimum requirements for Phase~2 catalogues.
-
-\note{Phase 2 command: P2 (exposure.ota.fits)}
-\note{Megacam: P2 654321o.fits[ccd00] - what are output names?}
-\note{PS FPA is saved as a collection of MEF files.  Megacam FPA is
+Though further details may be required for catalogs in Phase~4,
+the above details are minimum requirements for Phase~2 catalogs.
+
+\tbd{Phase 2 command: P2 (exposure.ota.fits)}
+\tbd{Megacam: P2 654321o.fits[ccd00] - what are output names?}
+\tbd{PS FPA is saved as a collection of MEF files.  Megacam FPA is
   saved as a single MEF file.  how to handle this difference?}
 
@@ -1439,17 +1466,15 @@
 \begin{figure}
 \begin{center}
-\resizebox{8cm}{!}{\includegraphics{pics/phase3.ps}}
+\resizebox{8cm}{!}{\includegraphics{pics/phase3}}
 \caption{ \label{phase3} Phase 3 dataflow}
 \end{center}
 \end{figure}
 
-Phase 3 : image processing preparation
-
-The Phase 3 system operates on the combined Phase 2 results from a
-collection of FPA images to determine improved solutions for the image
-calibrations and to provide the parameters needed by Phase 4.  The
-Phase 3 output is saved by the IID, and consists largely of improved
-values of the calibrations already determined by Phase 2.  The
-analysis performed by this pipeline consists of:
+The Phase 3 system operates on the combined Phase 2 results from an
+FPA to determine improved solutions for the image calibrations and to
+provide the parameters needed by Phase 4.  The Phase 3 output is saved
+by the IMD, and consists largely of improved values of the
+calibrations already determined by Phase 2.  The analysis performed by
+this pipeline consists of:
 
 \begin{itemize}
@@ -1460,5 +1485,4 @@
 \item photometric solution based on comparison to photometric
   standards
-\item PSF convolution kernels to transform images to a common PSF.
 \end{itemize}
 
@@ -1466,6 +1490,6 @@
 independently for each OTA.  These solutions are limited by the
 assumption of a static distortion and \tbd{by the accuracy of the
-  astrometric reference}.  In the phase 3 analysis, the astrometric
-solutions of the N FPA images are improved by ???
+astrometric reference}.  In the phase 3 analysis, the astrometric
+solutions of the N FPA images are improved by \tbd{???}.
 
 \tbd{what is the expected accuracy of the relative astrometric
@@ -1488,9 +1512,10 @@
 absolute photometry solution? (probably)}
 
-In the Phase 4 analysis, N FPA images are optimally combined to create
-a single image of the sky with bad-pixel and cosmic-ray rejection.
-This combination requires the calculation of a set of PSF kernels to
-convert each of the input images to a single, common PSF.  These PSF
-kernels are determined from the per-OTA PSFs measured in Phase 2.
+In the Phase 4 analysis, the $N$ FPA images are optimally combined to
+create a single image of the sky with bad-pixel and cosmic-ray
+rejection.  This combination requires the calculation of a set of PSF
+kernels to convert each of the input images to a single, common PSF.
+These PSF kernels are determined from the per-OTA PSFs measured in
+Phase 2.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -1499,5 +1524,5 @@
 \begin{figure}
 \begin{center}
-\resizebox{8cm}{!}{\includegraphics{pics/phase4.ps}}
+\resizebox{8cm}{!}{\includegraphics{pics/phase4}}
 \caption{ \label{phase4} Phase 4 dataflow}
 \end{center}
@@ -1506,10 +1531,10 @@
 \paragraph{Phase 4 Concept}
 
-Phase 4 processing within the Pan-STARRS image processing pipeline is
+Phase 4 processing within the \PS{} image processing pipeline is
 the final stage of processing for a science image.  It operates on
 each sky cell that has overlapping imaging data from the exposure(s)
 being processed, and produces the main output image data products of
 the pipeline --- the difference images and a deep static sky image ---
-along with the associated catalogues of static and variable sources.
+along with the associated catalogs of static and variable sources.
 
 Prior to Phase 4, the Phase 3 process produces the following products:
@@ -1518,7 +1543,6 @@
 \item photometric calibration;
 \item astrometric calibration with mapping to sky cells; and
-\item PSF models for the images.
 \end{itemize}
-These will each be used by the Phase 4 tasks:
+These will each be used by the Phase 4 modules:
 \begin{enumerate}
 \item Combine Images;
@@ -1527,16 +1551,16 @@
 \item Add to Static Sky.
 \end{enumerate}
-These tasks are each explained below.
+These modules are each explained below.
 
 \paragraph{Combine Images}
 
-The first task for Phase 4 is to combine the images from each
+The first module for Phase 4 is to combine the images from each
 telescope, rejecting artifacts such as cosmic rays and low altitude
-streaks.  The inputs to this task are:
+streaks.  The inputs to this module are:
 \begin{enumerate}
 \item the sky-subtracted images that overlap the sky cell (or portions
 thereof) --- from the IPP Pixel Server (or directly from Phase 3);
-\item a (linear) map for the image pixels of each detector to the sky
-cell pixels --- from Phase 3;
+\item a \tbd{linear} map for the image pixels of each detector to the
+sky cell pixels --- from Phase 3;
 \item photometric calibration (zeropoint) for each image --- from
 Phase 3; and
@@ -1546,33 +1570,26 @@
 \end{enumerate}
 
-The task maps the detector images to the sky cell using the specified
+The module maps the detector images to the sky cell using the specified
 linear transformations, combines the images with strong rejection
 criteria and uses the combined sky cell image to identify artifacts in
 the original detector images.  It is desirable that the artifacts are
 masked in the detector plane (i.e.\ before mapping to the sky cell) so
-that they are not smeared out by the mapping.  The masked detector
-images are then mapped to the sky cell and optimally combined using
-the specified weighting.  Both sets of combinations use the
-photometric calibration for the images to set the relative scales of
-the input images.  The final combination should have the adopted
-Universal zeropoint (25 mag, configurable).
-
-A PSF model for the combined sky cell image should be made by
-identifying point sources in the combined image, scaling and stacking
-them to achieve high signal-to-noise, and fitting with an analytic
-functional form (e.g. Gaussian, Moffat, Waussian).  The limiting
-magnitude for the combined sky cell image should also be estimated.
-
-The outputs from this task are:
+that they are not smeared out by the mapping; alternatively, the CR
+mask needs to be grown by an additional pixel (which is likely
+faster).  The mapped and masked detector images are then optimally
+combined using the specified weighting.  Both sets of combinations use
+the photometric calibration for the images to set the relative scales
+of the input images.  The final combination should have the adopted
+Universal zeropoint (25 mag, configurable).  The limiting magnitude
+for the combined sky cell image should also be estimated.
+
+The outputs from this module are:
 \begin{enumerate}
 \item The combined sky cell image --- sent to the IPP Pixel Server
-and/or the next task;
-\item PSF model for the combined sky cell image --- metadata
-associated with the combined sky cell image, and used for the other
-tasks in Phase 4;
+and/or the next module;
 \item Limiting magnitude of the combined sky cell image --- metadata
-associated with the combined sky cell image, and used for a later task
+associated with the combined sky cell image, and used for a later module
 in Phase 4; and
-\item Catalogue of sources on the combined sky cell image --- sent to
+\item Catalog of sources on the combined sky cell image --- sent to
 the IPP Object Database.
 \end{enumerate}
@@ -1581,41 +1598,30 @@
 \paragraph{Identify Sources}
 
-This task identifies sources in the combined sky cell image.  The
-inputs are:
-\begin{enumerate}
-\item The combined sky cell image --- from the IPP Pixel Server
-or the previous task;
-\item PSF model for the combined sky cell image --- metadata
-associated with the combined sky cell image, from the previous task;
-\end{enumerate}
+This module identifies sources in the combined sky cell image.  The
+input is the combined sky cell image, which is obtained from the IPP Pixel Server
+or the previous module.
 
 Sources are identified on the combined sky cell image by convolving
-with the PSF model and searching for peaks above the noise.  The output
-is:
-\begin{enumerate}
-\item Catalogue of sources on the combined sky cell image --- sent to
+with the PSF and searching for peaks above the noise.  The output
+is the catalog of sources on the combined sky cell image, which is to
 the IPP Object Database.
-\end{enumerate}
  
 
 \paragraph{Transient Identification}
 
-This task identifies variable/moving sources.  The inputs are:
-\begin{enumerate}
-\item The combined sky cell image --- from the previous task or the
-IPP Pixel Server;
-\item The PSF model for the combined sky cell image from the previous
-task --- from the Metadata database, or the previous task;
-\item The current static sky image --- from the Sky Image Server; and
-\item The PSF model for the static sky image --- from the metadata or
-the Sky Image Server.
-\end{enumerate}
-
-The task subtracts the current static sky image from the combined sky
+This module identifies variable/moving sources.  The inputs are:
+\begin{enumerate}
+\item The combined sky cell image --- from the previous module or the
+IPP Pixel Server; and
+\item The current static sky image --- from the Sky Image Server.
+\end{enumerate}
+
+The module subtracts the current static sky image from the combined sky
 cell image.  In order to do so, the PSFs need to be matched.  This is
 done by convolving the image that has the narrower PSF with the
 kernel, which is the ratio of the two PSFs (this should be done with a
-fit to the PSFs instead of just using the data).  It should be
-sufficient to assume that the kernel is constant over the sky cell.
+fit to the kernel instead of just using the data).  It should be
+sufficient to assume that the kernel is constant over the sky cell
+(otherwise, the sky cell can be broken into smaller sections).
 
 The subtracted image is scoured for point sources above the noise
@@ -1639,11 +1645,11 @@
 per day.
 
-The task outputs:
+The module outputs:
 \begin{enumerate}
 \item Combined sky cell image, with all variable sources masked ---
-used for the next task;
+used for the next module;
 \item Subtracted image, with long trails masked --- sent to the IPP
 Pixel Server; and
-\item Catalogue of variable sources --- sent to the IPP Object
+\item Catalog of variable sources --- sent to the IPP Object
 Database.
 \end{enumerate}
@@ -1652,10 +1658,12 @@
 \paragraph{Add to Static Sky}
 
-This task adds the combined sky cell image into the static sky, so
-that a deep image of the sky may be formed.  The inputs are:
+This module adds the combined sky cell image into the static sky, so
+that a deep image of the sky may be formed.  This step should only be
+performed if the new data is of sufficient quality that it will not
+degrade the static sky image.  The inputs are:
 \begin{enumerate}
 \item The combined sky cell image with variable sources masked ---
-from a previous task;
-\item The current version of the static sky --- from a previous task,
+from a previous module;
+\item The current version of the static sky --- from a previous module,
 or the IPP Pixel Server; and
 \item Relative weightings, based on the relative signal-to-noise in
@@ -1674,5 +1682,5 @@
 \begin{enumerate}
 \item The new static sky image --- sent to the Sky Image Server;
-\item The Catalogue of sources on the new static sky image --- sent to the IPP Object Database; and
+\item The Catalog of sources on the new static sky image --- sent to the IPP Object Database; and
 \item The estimated limiting magnitude for the new static sky ---
 metadata associated with the the new static sky image.
@@ -1682,5 +1690,5 @@
 
 \begin{itemize}
-\item Catalogues should include positional information ($x,y$, with
+\item Catalogs should include positional information ($x,y$, with
 associated errors), photometry (with associated error), and shape
 parameters (FWHM, major and minor axes, position angle).
@@ -1693,15 +1701,15 @@
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\subsubsection{basic detrend image creation}
+\subsubsection{Basic detrend image creation}
 
 The basic detrend image creation pipeline collects the appropriate
 input detrend images (bias, dark, flat, etc?) and generates a master
-image by combining the input images in some optimal way (median /
-sigma-clipping / etc).  The master image is used to determine input
-image residuals so that poor input images can be iteratively
-rejected.  
+image by combining the input images in some optimal way
+\tbd{median/sigma-clipping/etc}.  The master image is used to
+determine input image residuals so that poor input images can be
+iteratively rejected.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\subsubsection{fringe pattern and sky foreground model creation}
+\subsubsection{Fringe pattern and sky foreground model creation}
 
 The fringe model creation and sky foreground model creation pipelines
@@ -1715,5 +1723,5 @@
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\subsubsection{photometric flat correction image creation}
+\subsubsection{Photometric flat correction image creation}
 
 The photometric flat-field correction uses images which have been
@@ -1727,21 +1735,33 @@
 \subsubsection{Astrometric Reference Catalog}
 
+For PS1, this shall be UCAC.
+
+For PS4, this shall be the PS1 catalog.
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \subsubsection{Photometric Reference Catalog}
 
+For PS1, absolute photometry will not be available until the master
+fit which will be performed when all data is taken.  For purposes of
+relative photometric extinction, the guide star brightnesses should be
+sufficient.
+
+For PS4, the PS1 catalogue shall be used.
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \subsection{Modules}
 
-\subsection{PanSTARRS Library}
+\subsection{\PS{} Library}
 
 \subsection{Internal Interfaces}
 
-Internal interfaces consist of queries to the IID or IPS, insertion of
-data in the IID, IPS, or IOD, or processing configuration files.  The
+Internal interfaces consist of queries to the IMD or IPS, insertion of
+data in the IMD, IPS, or IOD, or processing configuration files.  The
 science and calibration image processing pipelines make requests for
-images from the IPS, meta-data from the IID, and push their results
-back onto the IPS and IID.  The reference catalog pipelines make
-requests on the IID and the IOD and push their results back to the
+images from the IPS, metadata from the IMD, and push their results
+back onto the IPS and IMD.  The reference catalog pipelines make
+requests on the IMD and the IOD and push their results back to the
 IOD.  The scheduler creates input processing configuration files for
-the processing pipelines and queries the IID and IPS and pushes
+the processing pipelines and queries the IMD and IPS and pushes
 results back to the IIS.
 
@@ -1761,23 +1781,23 @@
 
 This subsection describes the interfaces between the IPP and other
-Pan-STARRS systems and the external clients.  The interfaces are
-illustrated in Figure NN.  Incoming data is received by either the IPS
-(pixels), the IID (meta-data), or the IOD (objects).  Requests for
-data by external clients are also made to these three databases.
-Requests for data made by the IPP are generated by the IPP Schdeduler
-or the science processing pipelines.  
+\PS{} systems and the external clients.  The interfaces are
+illustrated in Figure \tbd{NN}.  Incoming data is received by either
+the IPS (pixels), the IMD (metadata), or the IOD (objects).  Requests
+for data by external clients are also made to these three databases.
+Requests for data made by the IPP are generated by the IPP Scheduler
+or the science processing pipelines.
 
 \subsubsection{OATS}
 
-The Summit Pixel Server (SPS) sends raw image data, image meta-data,
-and enviromental meta-data to the IPP.  The IPP provides an interface
+The Summit Pixel Server (SPS) sends raw image data, image metadata,
+and enviromental metadata to the IPP.  The IPP provides an interface
 mechanism by which the SPS can register new images with the IPP, which
 sends them to the appropiate subsystem: The image pixel data is sent
-to the IPS while the metadata is sent to the IID.
-
-The Pan-STARRS Telescope Scheduler (PTS) sends information about the
-telescope schelude to the IPP: observing plan for the night, or longer
+to the IPS while the metadata is sent to the IMD.
+
+The \PS{} Telescope Scheduler (PTS) sends information about the
+telescope schedule to the IPP: observing plan for the night, or longer
 time scales.  The IPP scheduler sends telescope schedule requests to
-the PTS.
+the PTS (i.e.\ calibration needs).
 
 \subsubsection{Published Static Sky Server}
@@ -1788,5 +1808,5 @@
 provides updated static sky images to the SIS when available.
 
-\subsubsection{Published Object Database}
+\subsubsection{Object Database}
 
 The Master Science Object Database receives new object photometry from
@@ -1795,16 +1815,14 @@
 timescale.  Is this a function of the IOD?}
 
-\subsubsection{Moving Object Pipeline}
-
-The Moving Object Pipeline interfaces with the IPP to receive the
-objects detected in the difference images.  \tbd{Does the IPP IOD push
-the objects out or respond to requests for new objects?}  The MOP
-sends the IPP the current set of known ephemerids for objects as
-requested. The MOP may interface with the IID as needed.
+\subsubsection{Moving Object Processing System}
+
+The Moving Object Processing System interfaces with the IPP to receive
+the objects detected in the difference images via queries to the IOD.
+The MOPS may interface with the IMD as needed.
 
 \subsubsection{Other Client Science Pipelines}
 
 The client science pipelines may interface with the IPP via requests
-for data from the IID, IOD, or IPS.  \tbd{how many clients max? / how
+for data from the IMD, IOD, or IPS.  \tbd{how many clients max? / how
 much data?}
 
@@ -1813,5 +1831,5 @@
 \subsubsection{Overview}
 
-This document discusses the likely range of the Pan-STARRS Image
+This document discusses the likely range of the \PS{} Image
 Processing Pipeline (IPP) hardware requirements.  The hardware
 requirements addressed in this document consist of:
@@ -1866,6 +1884,6 @@
 organization scenario, which will require the software to track the
 location of data products more carefully.  In addition, this document
-will address the data requirements of the complete Pan-STARRS pipeline
-with 4 telescopes as well as the single-telescope Pan-STARRS-1 scenario
+will address the data requirements of the complete \PS{} pipeline
+with 4 telescopes as well as the single-telescope \PS{}-1 scenario
 based on the Design Reference Mission [REF].
 
@@ -1893,5 +1911,5 @@
 currently possible to buy a single switch which would have a
 sufficient number of GigE ports for both sections of the PS-1 system,
-such a two-switch organization may be needed for the full Pan-STARRS
+such a two-switch organization may be needed for the full \PS{}
 system.  In such a case, the interswitch communication must also meet
 the required throughput needs.  We discuss the hardware requirements
@@ -1989,5 +2007,5 @@
 \subsubsection{Data Storage Requirements}
 
-The Pan-STARRS IPP data storage requirements may be divided into five
+The \PS{} IPP data storage requirements may be divided into five
 principal areas: raw image data, static sky image data, master
 calibration images, the metadata database, and the object database.
@@ -2367,5 +2385,5 @@
 roughly 60-70 Sky-cells per exposure set.  Thus the Phase 4 processing
 adds an additional 750 MB/sec network bandwidth.  In the architecture
-defined in Figure NN, the Sky nodes and the OTA nodes are each
+defined in Figure \tbd{NN}, the Sky nodes and the OTA nodes are each
 attached to separate switches.  An additional bandwidth requirement is
 derived by the need to exchange data between these switches in for
@@ -2501,7 +2519,7 @@
 reliable and robust to missing elements.  If a specific cell is
 missing from an OTA, that information is known by the controller an
-needs to be represented in the meta-data.  Similarly if an OTA is
+needs to be represented in the metadata.  Similarly if an OTA is
 missing from a mosaic camera, that information is also known and must
-be carried though the meta-data.  A more difficult association is that
+be carried though the metadata.  A more difficult association is that
 between the telescopes to define the major frame.  Some possibilities:
 
@@ -2517,5 +2535,5 @@
 appropriate, some varient is required).
 \item exposure links are defined more generally on the basis of the
-resulting image meta-data.  The telescopes may have images requested
+resulting image metadata.  The telescopes may have images requested
 at the same coordinates and time, and are defined as a major frame on
 the basis of the observed time and coordinates.  The TCS or PTS might
@@ -2612,18 +2630,18 @@
 and their orbital elements, and the time range for the calculation.
 If the calculation is slow, Phase 0 could be paralellized by object.
-If Phase 0 is fast enough ({\bf minutes?}), the process need not be
+If Phase 0 is fast enough (\tbd{minutes?}), the process need not be
 parallel.  The {\tt lifetime} and {\tt date of calculation} allow old
-Phase 0 entries to be removed when they are not needed.  {\bf [This
-cleaning phase could be a function of Phase 0.]}.  Phase 0 need not be
+Phase 0 entries to be removed when they are not needed.  \tbd{This
+cleaning phase could be a function of Phase 0.}  Phase 0 need not be
 run only for the current night.  Any time a specific set of data is to
 be analysed by the later stages, phase 0 should be run for the
-appropriate time period.  {\bf [Does there need to be a database table
+appropriate time period.  \tbd{Does there need to be a database table
 with phase 0 runs and time periods defined?  this could be the
 reference used by later phases to decide if phase 0 has been run. they
 could also trigger the phase 0 run if they notice it has not been run
-(a job of the scheduler).]}
-
-{\bf TBD: what is the orbit calculation speed?  does it scale with
-Npts?  what is the number of known objects now? in 5 years?}
+(a job of the scheduler).}
+
+\tbd{what is the orbit calculation speed?  does it scale with Npts?
+what is the number of known objects now? in 5 years?}
 
 
@@ -2670,8 +2688,8 @@
 affect the flux in neighbouring pixels
 
-\milsection{Object Catalogues}
-\label{ap:catalogues}
-
-Object catalogues from Phase 2 shall consist of at least the
+\milsection{Object Catalogs}
+\label{ap:catalogs}
+
+Object catalogs from Phase 2 shall consist of at least the
 following elements for each object:
 \begin{enumerate}
@@ -2684,5 +2702,5 @@
 \end{enumerate}
 
-Though further details may be required for catalogues in Phase~4,
-the above details are minimum requirements for Phase~2 catalogues.
-
+Though further details may be required for catalogs in Phase~4,
+the above details are minimum requirements for Phase~2 catalogs.
+