Index: /trunk/doc/design/design.tex
===================================================================
--- /trunk/doc/design/design.tex	(revision 509)
+++ /trunk/doc/design/design.tex	(revision 510)
@@ -1,3 +1,3 @@
-%%% $Id: design.tex,v 1.7 2004-04-23 02:44:14 price Exp $
+%%% $Id: design.tex,v 1.8 2004-04-23 04:06:00 price Exp $
 \documentclass[panstarrs]{panstarrs}
 
@@ -191,44 +191,59 @@
 \resizebox{8cm}{!}{\includegraphics{pics/overview}}
 \caption{ \label{overview} IPP System Overview. \tbd{``Processing
-Jobs'' should be renamed ``Analysis Pipelines''.} }
+Jobs'' should be renamed ``Analysis Stages''.} }
 \end{center}
 \end{figure}
 
-\subsubsection{Analysis Pipelines}
-
-We now consider the collection of IPP analysis pipelines.  Depending
-on the particular pipeline, they may be run on individual images,
-collections of images, or on derived data products.  Because of the
-nature of the image data, many of the analysis pipelines 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.  We define the
-analysis pipelines to be the largest complete analysis task which may
-be performed on a single data item.  The data analysis tasks are
-divided into three categories, and further subdivided as follows:
-
-\begin{enumerate}
-\item Science Image Pipelines
+\subsubsection{Analysis Stages}
+
+We now consider the collection of IPP analysis stages.  We define an
+analysis stage to be the largest complete task which may be performed
+in serial without interation between parallel threads.
+
+Depending on the particular analysis 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.
+
+The data analysis stages are divided into three categories as follows:
+
+\begin{enumerate}
+\item Science Image Analysis Stages
   \begin{enumerate}
-  \item Phase 1: image processing preparation
-  \item Phase 2: image reduction
-  \item Phase 3: exposure analysis
-  \item Phase 4: image combination
+  \item Phase 1: image processing preparation --- estimates
+    first-order astrometric and photometric solutions required to
+    process each major frame.
+  \item Phase 2: image reduction --- produces calibrated chips from
+    raw chips.
+  \item Phase 3: exposure analysis --- processes an FPA to produce
+    unified and consistent backgrounds, photometry and astrometry for
+    the component chips.
+  \item Phase 4: image combination --- processes sky cells overlapped
+    by a major frame.
   \end{enumerate}
-\item Calibration Image Pipelines
+\item Calibration Image Analysis Stages
   \begin{enumerate}
-  \item Calibration 1: basic master-detrend creation
-  \item Calibration 2: Sky-model/fringe-mode generation
-  \item Calibration 3: Flat-field correction image Creation
+  \item Calibration 1: Basic master-detrend creation --- combination
+    of simple detrend images.
+  \item Calibration 2: Sky-model/fringe-mode generation ---
+    combination of more-complicated detrend images.
+  \item Calibration 3: Flat-field correction image creation ---
+    analysis of photometry from multiple dithered FPAs.
   \end{enumerate}
-\item Reference Catalog Pipelines
+\item Reference Catalog Analysis Stages
   \begin{enumerate}
-  \item Astrometry reference catalog generation
-  \item Photometry reference catalog generation
+  \item Astrometry reference catalog generation --- processing of the
+    astrometric data to determine and apply a consistent global
+    solution.
+  \item Photometry reference catalog generation --- processing of the
+    photometric data to determine and apply a consistent global
+    solution.
   \end{enumerate}
 \end{enumerate}
 
-Figure~\ref{pipelines} shows the flow of data between the various IPP
-software systems and the different analysis tasks, each managed by the
-controller.  The thick lines represent the flow of pixel data, the
+Figure~\ref{system} shows the flow of data between the various IPP
+software systems and the different analysis stages, each managed by
+the 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.  The hatched systems
@@ -240,5 +255,5 @@
 \begin{center}
 \resizebox{8cm}{!}{\includegraphics{pics/pipelines}}
-\caption{ \label{pipelines} IPP System Overview. \tbd{Small part at
+\caption{ \label{system} IPP System Overview. \tbd{Small part at
 top is missing.} }
 \end{center}
@@ -252,8 +267,8 @@
 the pre-reduction analysis of the raw science images.  In addition, we
 have specified distinct machines to maintain the object and metadata
-databases.  This last aspect is largely theoretical until we have
+databases.  \tbd{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 distribute these database
-elements across the Detector and Static Sky subclusters.
+elements across the Detector and Static Sky subclusters.}
 
 \begin{figure}
@@ -274,8 +289,9 @@
 frameworks.  In particular, the modules can be tied together with a
 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.
+the use of a high-level language such as Perl, Python, or Tcl
+employing the SWIG interfaces.  For the high-level functions in the
+operational system, the IPP will make use of \tbd{Python} as the
+scripting language to provide the required flow-control to tie the
+modules together.
 
 This approach satisfies the requirement that complicated low-level
@@ -304,10 +320,11 @@
 \subsubsection{Modules}
 
-The IPP analysis tasks are broken down into modules which represent
+The IPP analysis stages are broken down into modules which represent
 specific functional operations.  The modules will be written in C
 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.
+all public APIs for their use in processing stages.  Examples of
+modules are overscan subtraction and image combination.  Some modules
+(e.g.\ find objects on an image) will be used by multiple stages.
 
 \subsubsection{Stages}
@@ -334,6 +351,6 @@
 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 exposure 1234''.
+functionality is ``Retrieve exposure number 1234; run phase 1--4
+controllers on exposure 1234''.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%