Index: /trunk/doc/design/ippSDRS.tex
===================================================================
--- /trunk/doc/design/ippSDRS.tex	(revision 2170)
+++ /trunk/doc/design/ippSDRS.tex	(revision 2171)
@@ -1,3 +1,3 @@
-%%% $Id: ippSDRS.tex,v 1.6 2004-10-18 22:05:43 eugene Exp $
+%%% $Id: ippSDRS.tex,v 1.7 2004-10-19 01:35:26 eugene Exp $
 \documentclass[panstarrs]{panstarrs}
 
@@ -177,13 +177,4 @@
 will act as the long-term archive and publishing clearinghouse.
 
-An important operational choice for the IPP is the decision not to
-attempt to save all raw data.  Once the IPP is running in a standard
-operational mode, data will be processed by the pipeline and deleted
-when it is no longer needed.  Raw images will only be saved for a
-short period to allow tests and quality assurance, and potentially to
-allow systems which study transient phenomena to return to recent data
-for closer inspection.  In general, during normal operations, raw
-science images will be deleted after $\sim$1 month.
-
 The primary IPP hardware system on which the software operates will
 not be located at the summit.  Instead, because of thermal, power, and
@@ -193,124 +184,30 @@
 transfer time and cost.
 
-\subsection{Analysis Tasks and Stages} 
-
-Specific programs are required to perform the processing steps listed
-above.  These can be divided into well-defined analysis stages, each
-of which operates on a particular unit of data, such as a single OTA
-image or a collection of astronomical objects.  Analysis tasks
-representing the different analysis stages are performed on the IPP
-computer cluster.  Note the distinction between the generic analysis
-{\em stage} and a specific analysis {\em task}.  An analysis stage
-represents a type of analysis which is performed, such as the basic
-image calibration and object detection analysis.  An analysis task is
-a particular realization of an analysis stage, e.g., the analysis of
-OTA number 61 from exposure 654321 to produce a specific set of output
-data products.  The analysis stages are discussed in detail in
-Section~\ref{IPP:AnalysisStages}.
-
-Depending on the particular stage, it may process individual images,
-collections of images, or on derived data products.  Because of the
-nature of the image data, many of the analysis stages can be run in
-parallel because, for example, the analysis of a chip in one image
-does not depend on the results from another chip.
-
-\subsection{Architectural Components}
-
-In order to achieve the required functionality, the IPP provides an
-infrastructure within which the Analysis Stages above are exectuted.
-We have divided the IPP software infrastructure into a number of
-clearly-defined architectural software units, listed as follows:
-
-\begin{itemize}
-
-\item {\bf Image Server:} This component is a large data store for all
-  images used by the IPP, 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 Image
-  Server accepts the incoming data and stores it until it is no longer
-  needed by other portions of the IPP.  The Image Server is not
-  restricted to imaging data: it is capable of storing any large data
-  files which are not well-suited for inclusion in a more structured
-  relational database and for which access needs to be widely
-  available beyond the individual process which created the file.
-
-\item {\bf Astrometry \& Photometry Database (AP DB):} This component
-  stores and manipulates astronomical objects detected in various
-  images, as identified above, including individual measurements of
-  objects on the images, the summary information about those objects,
-  and reference object data.  It also provides mechanisms for users to
-  query and manipulate the objects and detections.
-
-\item {\bf Metadata Database:} This component stores the data which is
-  not directly related to images or astronomical objects, but which is
-  needed to perform the IPP analyses.  The metadata may include the
-  summary weather information for each night, or details about the
-  filters, camera, telescopes, etc.  
-
-\item {\bf IPP Controller:} In order to perform the analysis stages
-  required by the IPP, it is necessary to use distributed computing
-  processes on a large number of computers.  The IPP Controller
-  manages the collection of analysis tasks performed on these
-  machines.
-
-\item {\bf IPP Scheduler:} This component is a decision-making
-  mechanism which guides the operation of the IPP.  It evaluates the
-  currently available collection of data, identifies the necessary
-  analysis, and assigns the analysis tasks to the IPP Controller.
-
-\end{itemize}
-
-The relationship between these software units is shown in
-Figure~\ref{overview}.  This figure also shows the interactions
-between the IPP and other Pan-STARRS systems.  The architectural
-components are discussed in detail in
-Section~\ref{IPP:ArchComponents}.
-
-\begin{figure}
-\begin{center}
-\resizebox{6in}{!}{\includegraphics{pics/IPPoverview}}
-\caption{ \label{overview} IPP System Overview}
-\end{center}
-\end{figure}
-
-\subsection{IPP Hardware Organization}
-
-\begin{figure}
-\begin{center}
-%\resizebox{4.5in}{!}{\includegraphics{pics/IPPhardware}}
-\caption{ \label{hardware} IPP Hardware Organization}
-\end{center}
-\end{figure}
-
-The IPP needs substantial computer resources, both in terms of
-computational power and in terms of data storage and network
-bandwidth.  The IPP requires relatively large amounts of data storage
-space, primarily for the image data.  Image data is organized in two
-categories.  First, there is the per-OTA data -- data associated with
-specific OTAs, including the raw images, the calibration images, and
-temporary processed images at various stages.  Second, there is the
-data associated with the static sky imagery, which is in turn
-organized into smaller sky-cell units.  In addition to image data,
-there are the somewhat smaller data entities of the Metadata Database
-and AP Database.
-
-The computer hardware is organized into nodes which provide both data
-storage and computational resources.  The data storage nodes are
-divided into three classes: those which deal with the per-OTA image
-data, those that provide the storage for the static sky images, and
-those that provide the storage for the other data systems, the
-Metadata Database and the AP Database.  In addition, the computational
-tasks related to Phase 2 take place on the per-OTA storage nodes and
-the Phase 4 computation takes place on the static sky storage nodes.
-
-Figure~\ref{hardware} shows our basic concept for the hardware
-organization for the IPP.  This diagram shows the two types of compute
-nodes: OTA-level processing and storage nodes (dominated by Phase 2)
-and static sky processing and storage nodes (mostly Phase 4).  Also
-shown are two switches which divide the network into OTA and
-Static-Sky portions.  In such an organization, the interswitch
-communication must meet the throughput needs between these network
-portions.  The additional data systems (Metadata Database and AP
-Database) are also shown.
+This document defines the design requirements of the IPP for the PS-1
+prototype telescope.  Even so, much of the IPP design for PS-4 will be
+identical to or closely based on the PS-1 implementation.  The
+software organization and the infrastructure systems will be
+identical, with minor improvements in details.  The range analysis
+steps to be performed will be nearly identical, with some additional
+details added for PS-4 to improve the accuracy.
+
+In terms of the IPP, PS-1 differs from the complete PS-4 system in
+several important ways.  First, with only one telescope and camera,
+the data throughput rate is substantially reduce to a maximum of 1
+64-OTA image per 40 seconds rather than 4.  In addition, much of the
+PS-1 mission will be devoted to calibration and testing which will
+imply a different level of processing.  For a significant fraction of
+PS-1, data will be obtained for the AP Survey covering the entire
+$3\pi$ steradians of the sky accessible to PS-4.  These images will
+not initially be analysed to the level of having multiple images
+combined.  Rather, the analysis will only be performed for individual
+focal plane array images.  Only after the AP Survey is done, the
+analysis process has been validated, and the complete AP Survey
+reference catalog has been generated will it be possible to generate
+the first epoch static sky image, rougly 18 months into the PS-1
+mission.  This difference in approach has implications for the storage
+required by PS-1: rather than delete images soon after they have been
+used, raw images must be stored for at least the first 18 months of
+PS-1 operations.
 
 \subsection{System Design Decisions}
@@ -337,23 +234,154 @@
 System (MOPS), and potentially other client science pipelines.
 
+The requirements for the IPP, as identified in the IPP SRS (PSDC-REF)
+fall into several broad categories: Data analysis precision,
+throughput, system reliability, flexibility, testability, and
+traceability.  The details of the analysis tasks are specified in
+order to achieve the precision.  The architectural design as discussed
+below is motivated by the need for reliability and flexibility.  The
+hardware organization and the distributed / parallel processing model
+is motivated by the throughput requirements.  The need for flexibility
+and testability drives the software organization.  The need for simple
+testing procedures drives both the software organization and the
+separation of the system architecture into different infrastructure
+elements.
+
+\subsection{Analysis Tasks and Stages} 
+
+Specific programs are required to perform the processing steps listed
+above.  These can be divided into well-defined analysis stages, each
+of which operates on a particular unit of data, such as a single OTA
+image or a collection of astronomical objects.  Analysis tasks
+representing the different analysis stages are performed on the IPP
+computer cluster.  Note the distinction between the generic analysis
+{\em stage} and a specific analysis {\em task}.  An analysis stage
+represents a type of analysis which is performed, such as the basic
+image calibration and object detection analysis.  An analysis task is
+a particular realization of an analysis stage, e.g., the analysis of
+OTA number 61 from exposure 654321 to produce a specific set of output
+data products.  The analysis stages are discussed in detail in
+Section~\ref{IPP:AnalysisStages}.
+
+Depending on the particular stage, it may process individual images,
+collections of images, or on derived data products.  Because of the
+nature of the image data, many of the analysis stages can be run in
+parallel because, for example, the analysis of a chip in one image
+does not depend on the results from another chip.
+
+\subsection{Architectural Components}
+
+In order to achieve the required functionality, the IPP provides an
+infrastructure within which the Analysis Stages above are exectuted.
+In order to facilitate the subsystem testing, we have divided the IPP
+software infrastructure into a number of clearly-defined architectural
+software units, listed as follows:
+
+\begin{itemize}
+
+\item {\bf Image Server:} This component is a large data store for all
+  images used by the IPP, 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 Image
+  Server accepts the incoming data and stores it until it is no longer
+  needed by other portions of the IPP.  The Image Server is not
+  restricted to imaging data: it is capable of storing any large data
+  files which are not well-suited for inclusion in a more structured
+  relational database and for which access needs to be widely
+  available beyond the individual process which created the file.
+
+\item {\bf Metadata Database:} This component stores the data which is
+  not directly related to images or astronomical objects, but which is
+  needed to perform the IPP analyses.  The metadata may include the
+  summary weather information for each night, or details about the
+  filters, camera, telescopes, etc.  
+
+\item {\bf Astrometry \& Photometry Database (AP DB):} This component
+  stores and manipulates astronomical objects detected in various
+  images, as identified above, including individual measurements of
+  objects on the images, the summary information about those objects,
+  and reference object data.  It also provides mechanisms for users to
+  query and manipulate the objects and detections.
+
+\item {\bf IPP Controller:} In order to perform the analysis stages
+  required by the IPP, it is necessary to use distributed computing
+  processes on a large number of computers.  The IPP Controller
+  manages the collection of analysis tasks performed on these
+  machines.  
+
+\item {\bf IPP Scheduler:} This component is a decision-making
+  mechanism which guides the operation of the IPP.  It evaluates the
+  currently available collection of data, identifies the necessary
+  analysis, and assigns the analysis tasks to the IPP Controller.
+
+\end{itemize}
+
+The relationship between these software units is shown in
+Figure~\ref{overview}.  This figure also shows the interactions
+between the IPP and other Pan-STARRS systems.  The architectural
+components are discussed in detail in
+Section~\ref{IPP:ArchComponents}.
+
+\begin{figure}
+\begin{center}
+\resizebox{6in}{!}{\includegraphics{pics/IPPoverview}}
+\caption{ \label{overview} IPP System Overview}
+\end{center}
+\end{figure}
+
+\subsection{IPP Hardware Organization}
+
+\begin{figure}
+\begin{center}
+\resizebox{4.5in}{!}{\includegraphics{pics/IPPhardware}}
+\caption{ \label{hardware} IPP Hardware Organization}
+\end{center}
+\end{figure}
+
+The IPP needs substantial computer resources, both in terms of
+computational power and in terms of data storage and network
+bandwidth.  The IPP requires relatively large amounts of data storage
+space, primarily for the image data.  Image data is organized in two
+categories.  First, there is the per-OTA data -- data associated with
+specific OTAs, including the raw images, the calibration images, and
+temporary processed images at various stages.  Second, there is the
+data associated with the static sky imagery, which is in turn
+organized into smaller sky-cell units.  In addition to image data,
+there are the somewhat smaller data entities of the Metadata Database
+and AP Database.
+
+The computer hardware is organized into nodes which provide both data
+storage and computational resources.  The data storage nodes are
+divided into three classes: those which deal with the per-OTA image
+data, those that provide the storage for the static sky images, and
+those that provide the storage for the other data systems, the
+Metadata Database and the AP Database.  In addition, the computational
+tasks related to Phase 2 take place on the per-OTA storage nodes and
+the Phase 4 computation takes place on the static sky storage nodes.
+
+Figure~\ref{hardware} shows our basic concept for the hardware
+organization for the IPP.  This diagram shows the two types of compute
+nodes: OTA-level processing and storage nodes (dominated by Phase 2)
+and static sky processing and storage nodes (mostly Phase 4).  Also
+shown are two switches which divide the network into OTA and
+Static-Sky portions.  In such an organization, the interswitch
+communication must meet the throughput needs between these network
+portions.  The additional data systems (Metadata Database and AP
+Database) are also shown.
+
 \section{System Design : Architectural Components}
 
 \subsection{IPP Image Server}
 
-\begin{figure}
-% \psfig{file=pics/ImageServer,width=15cm,angle=0}
-\caption{The components of the IPP Image Server.}
-\label{fig:ImageServer}
-\end{figure}
+\subsubsection{Image Server Overview}
 
 The IPP Image Server is a repository for all images and other large
-data files required by the IPP.  In addition, it provides tools for
-managing the distribution of these large data files and for accessing
-the files.  Data files stored by the IPP Image Server include the raw
-images, the calibration images, intermediate processing stage images
-as needed, final processed images, difference images, image
-subsections, and any large non-imaging datafiles needed by the IPP.
-The IPP Image Server must retain the files for as long as they are
-needed by the IPP.
+data files required by the IPP.  Along with the storage hardware, it
+provides tools for managing the distribution of these large data files
+and for accessing the files.  Data files stored by the IPP Image
+Server include the raw images, the calibration images, intermediate
+processing stage images as needed, final processed images, difference
+images, image subsections, and any large non-imaging datafiles needed
+by the IPP.  The IPP Image Server must retain the files for as long as
+they are needed by the IPP.
 
 The IPP Image Server is a parallel storage system.  It stores data
@@ -372,5 +400,5 @@
 \begin{itemize}
 \item {\bf storage object} This represents a single, unique data
-  entity the Image Server.
+  entity in the Image Server.
 
 \item {\bf instance} A single copy of the storage object in the Image
@@ -384,8 +412,9 @@
 
 The Image Server provides file pointers (in C), handles (in Perl), or
-file names corresponding to the instances of the storage objects.
-Image Server requires a file system which provides files in the local
-file system.  This may be done over many machines with a network file
-system such as NFS or GFS.  
+file names corresponding to the instances of the storage objects.  The
+Image Server provides the data organization but does not define a file
+system; it assumes the existence of an appropriate file system which
+provides makes the files visible as local files.  This may be done
+over many machines with a network file system such as NFS or GFS.
 
 The IPP Image Server provides the storage and access mechanisms, but
@@ -403,9 +432,15 @@
 \end{itemize}
 
+\begin{figure}
+\resizebox{6in}{!}{\includegraphics{pics/ImageServer}}
+\caption{The components of the IPP Image Server.}
+\label{fig:ImageServer}
+\end{figure}
+
 \subsubsection{IPP Image Server Client APIs}
 
-Clients interact with the IPP Image Server with a small number of C
-APIs (Bindings are also provided for Perl \tbr{and Python}).  The
-client commands are:
+Clients interact with the IPP Image Server via a small number of C
+APIs (Bindings are also provided for Perl and Python).  The client
+commands are:
 
 \begin{itemize}
@@ -450,6 +485,8 @@
 
 The Image Server client requests are mediated via the Image Server
-daemon.  Communication between the clients and the server is via
-\tbr{SOAP (or flat text commands)} implementing the commands above.
+daemon.  Communication between the clients and the server is via SOAP
+implementing the commands above.  The identity of the machine on which
+Image Server daemon runs is part of the Image Server configuration
+information.
 
 \subsubsection{IPP Image Server Database}
@@ -461,5 +498,5 @@
 listed in Table~\ref{ImageServerTables}, and their current contents
 are listed in Appendix A.  This database engine need not the same one
-as used for the IPP Metadata Database.
+as the one used for othe IPP subsystems.
 %
 \begin{table}
@@ -581,4 +618,6 @@
 
 \subsection{AP Database}
+
+\subsubsection{Overview}
 
 The AP (Astrometry \& Photometry) Database is a mechanism to store