Index: /trunk/doc/design/design.tex =================================================================== --- /trunk/doc/design/design.tex (revision 409) +++ /trunk/doc/design/design.tex (revision 409) @@ -0,0 +1,2687 @@ +%\documentclass[panstarrs,psreport]{panstarrs} +\documentclass[panstarrs]{panstarrs} + +% basic document variables +\title{Pan-STARRS Image Processing Pipeline Supplementary Design Requirements} +\shorttitle{IPP SSDD} +\author{Eugene Magnier, Paul Price, Josh Hoblitt} +\group{Pan-STARRS Algorithm Group} +\project{Pan-STARRS Image Processing Pipeline} +\organization{Institute for Astronomy} +\version{DR} +\docnumber{PSDC-430-008} + +\begin{document} +\maketitle + +% -- Revision History -- +% provide explicit values for the old versions +% use '\theversion' for the current version (set above) +\RevisionsStart +% version Date Description +01 & 2003.01.01 & First draft \\ +\hline +02 & 2003.03.05 & Second draft \\ +\hline +03 & 2003.03.25 & Section reorganization \\ +\RevisionsEnd + +\pagebreak +\tableofcontents + +\pagebreak +\listoffigures + +\pagebreak +\pagenumbering{arabic} +\section{Scope} + +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) +and the initial single-telescope demonstration deployment (PS-1). + +\subsection{Identification} + +\subsection{System Overview} + +\subsection{Document Overview} + +Open Issues and TBDs in this document are marked in bold with +surrounding square brackets. + +\section{Referenced Documents} + +This section lists documents referred to by this specification.\\ + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Internal Documents} \\ +xxx-xxx-xxx & Pan-STARRS Telescope Scheduler specification document \\ +xxx-xxx-xxx & Telescope Control System specification document \\ +xxx-xxx-xxx & Summit Pixel Server specification document \\ +xxx-xxx-xxx & Sky Server specification document \\ +xxx-xxx-xxx & Master Object Database specification document \\ +xxx-xxx-xxx & Camera Readout specification document \\ +xxx-xxx-xxx & PS-1 Design Reference Mission \\ +xxx-xxx-xxx & Pan-STARRS C Code Conventions \\ +\hline +\multicolumn{2}{l}{\bf External Documents} \\ +Posix Standard & Open Group Based Specifications Issue 6, IEEE Std 1003.1, 2003 \\ +\hline +\end{tabular} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\section{System Design Decisions} + +Pan-STARRS 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 +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 +(IPP) and the appropriate resulting data products made available to +internal and external science analysis systems as they become +available. The processing performed by the IPP on the science images +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 +object analysis of the static sky images. In addition, the IPP will +produce improved astrometric and photometric reference catalogs on an +occasional basis as needed. The output data products from the IPP +consist of the calibration images, reduced images from the individual +telescopes, combined images, difference images, the static sky image, +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 +collection of computer hardware and software organized to perform the +tasks required to process images from the Pan-STARRS 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 +other analysis functions to generate the calibrations needed in the +science image processing and to occasionally use the derived data to +generate improved astrometric and photometric reference catalogs. + +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 +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. + +The IPP architecture can be viewed in several possible ways. We first +consider the software architecture components needed by the IPP. +These subsystems provide the infrastructure for the data storage and +the data processing. Next, we consider the analysis pipelines which +make up the major processing tasks that must be performed by the IPP. +Finally, we consider the hardware organization required to efficiently +and cost-effectively achieve the necessary computing and storage +requirements. + +\subsection{System Overview} +\subsection{System Architecture} +\subsubsection{Architectural Components} + +The IPP is organised into several different software elements, listed +as follows: + +\begin{enumerate} +\item Pixel Server +\item Object Database +\item Metadata Database +\item Analysis Pipelines +\item Controller +\item Scheduler +\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. + +\begin{figure} +\begin{center} +\resizebox{8cm}{!}{\includegraphics{pics/overview.ps}} +\caption{ \label{overview} IPP System Overview} +\end{center} +\end{figure} + +\subsubsection{Analysis Stages} + +We now consider the collection of analysis tasks which are performed +by the IPP. Depending on the task, they may be performed on +individual images, collections of images, or on derived data products. +Because of the nature of the image data, many of the analysis tasks +can be performed in parallel because, for example, the analysis of an +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: + +\begin{enumerate} + \item Science Image Pipelines + \begin{enumerate} + \item Phase 1 : image processing preparation + \item Phase 2 : image reduction + \item Phase 3 : exposure analysis + \item Phase 4 : image combination + \end{enumerate} + \item Calibration Image Pipelines + \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 + \end{enumerate} + \item Reference Catalog Pipelines + \begin{enumerate} + \item Astrometry reference catalog generation + \item Photometry reference catalog generation + \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 +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. + +\begin{figure} +\begin{center} +\resizebox{8cm}{!}{\includegraphics{pics/pipelines.ps}} +\caption{ \label{pipelines} IPP System Overview} +\end{center} +\end{figure} + +\subsubsection{Hardware Systems} + +The basic IPP hardware organization is shown in Figure~\ref{hardware}. +The overall hardware organization, with an OTA subcluster and a +Static-Sky subcluster, is largely chosen to reduce the I/O load during +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 +defined the details of these databases; it may be more appropriate +depending on the eventual solutions to distribution these database +elements across the OTA and Static Sky subclusters. + +\begin{figure} +\begin{center} +\resizebox{8cm}{!}{\includegraphics{pics/hardware.ps}} +\caption{ \label{hardware} IPP Hardware Organization} +\end{center} +\end{figure} + +\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 +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 +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. + +\subsubsection{Modules} + +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. + +\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. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\subsection{System Interfaces} + +\section{System Architectural Design} + +\subsection{Architectural Components} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\subsubsection{Pixel Server} + +The IPP Pixel Server (IPS) is a repository for all image pixel data +required by the IPP. Images may reside in the IPS for different +periods depending on their use and type. Images stored by the IPS +include the raw images, the calibration images, intermediate +processing stage images as needed, final processed images, difference +images, and image subsections. The IPS must retain images as long as +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 +associating specific machines with specific OTAs. The IPS interacts +with the IPP Internal 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. + +\paragraph{Pixel Server Components} + +The Pixel Server consists of the following components: + +\begin{enumerate} +\item IPP Pixel Data Scheduler +\item IPP Pixel Data Locality Optimizer +\item IPP Pixel Data Database +\item IPP Pixel Data Retrieval Agent +\item IPP Pixel Data Query Library +\item IPP Pixel Data I/O Library +\end{enumerate} + +\subparagraph{IPP Pixel Data Scheduler (IPP-PDS)} + +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. + +\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. +\end{itemize} + +\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. + +\subparagraph{IPP Pixel Data Database (IPP-PDD)} + +The IPP Pixel Data Database contains image data locations and the associated +meta-data. + +The IPP-PDD will contain at least: + +\begin{itemize} +\item The location of image data and it's associated meta-data 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 +processing within the IPP System. +\item The location of reduced image data and it's associated meta-data as +generated by the IPP System. +\item The location of difference image data and it's associated meta-data as +generated by the IPP System. +\item The location of stacked image data and it's associated meta-data as +generated by the IPP System. +\item A history of data management commands and actions. +\end{itemize} + +\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: + +\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. +\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} + +\subparagraph{Acquisition} + +\begin{enumerate} +\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 Scheduler updates the IPP Pixel Data Database to +the new storage location. +\item The IPP Pixel Data Scheduler notifies the IPP Scheduler that new data is +available by appending to a notification table in the IPP Pixel Data Database. +\tbd{In addition a notification maybe sent directly to the IPP Scheduler.} +\end{enumerate} + +\begin{figure} +\begin{center} +%\resizebox{!}{20cm}{\includegraphics{data_stack8.epsi}} +\caption{ \label{acquisition} Pixel Data Flow: Acquisition} +\end{center} +\end{figure} + +\subparagraph{Processing} + +\begin{enumerate} + +\item The IPP Scheduler gives the IPP Controller a Phase 2 image processing task. + +\begin{enumerate} +\item The IPP Controller passes the task to a \tbd{IPP Node Agent}. +\item The \tbd{IPP Node Agent} {\em spawns} a \tbd{IPP Image Processing Agent} and +passes it the task. +\item The \tbd{IPP Image Processing Agent} retrieves the exposure data to be processed +with the IPP Pixel Data I/O library and loads it into local memory. +\item The \tbd{IPP Image Processing Agent} retrieves the calibration data with +the IPP Pixel Data I/O library and loads it into local memory. +\item The \tbd{IPP Image Processing Agent} processes the Phase 2 task. +\item The \tbd{IPP Image Processing Agent} stores the processed data with the +IPP Pixel Data I/O library. +\end{enumerate} + +\item The IPP Scheduler gives the IPP Controller a Stage 4 image processing task. + +\begin{enumerate} +\item The IPP Controller passes the task to a \tbd{IPP Node Agent}. +\item The \tbd{IPP Node Agent} {\em spawns} a \tbd{IPP Image Processing Agent} and +passes it the task. +\item The \tbd{IPP Image Processing Agent} retrieves the reduced image data +with the IPP Pixel Data I/O library and loads it into local memory. +\item The \tbd{IPP Image Processing Agent} retrieves the best stacked image +data with the IPP Pixel Data I/O library and loads it into local memory. +\item The \tbd{IPP Image Processing Agent} retrieves the current working +stacked image data with the IPP Pixel Data I/O library and loads it into +local memory. +\item The \tbd{IPP Image Processing Agent} processes the Phase 4 task. +\item The \tbd{IPP Image Processing Agent} stores the difference image with +the IPP Pixel Data I/O library. +\item The \tbd{IPP Image Processing Agent} stores the new working stacked +image with the IPP Pixel Data I/O library. +\end{enumerate} +\end{enumerate} + +\begin{figure} +\begin{center} +%\resizebox{!}{20cm}{\includegraphics{data_processing1.epsi}} +\caption{ \label{processing} Pixel Data Flow: Processing} +\end{center} +\end{figure} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%5 + +\subsubsection{Metadata Database} + +The IPP Metadata Database acts as a repository for all non-pixel data +needed by the IPP subsystems. This includes the image metadata, the +environmental data, system configuration data and system reference +data. The Metadata Database is required to save the non-ephemeral +data for the lifetime of the project for future reference and +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. + +\paragraph{Metadata Tables} + +Table NN lists the Metadata tables identified for the Metadata +Database. + +\begin{tabular}{l} +\hline +\multicolumn{1}{l}{\bf Metadata Tables} \\ +weather \\ +SkyProbe \\ +LRProbe \\ +DIMM \\ +NIR \\ +Dome Status \\ +Telescope Status \\ +Raw FPAs \\ +Raw OTAs \\ +Raw Cells \\ +Observation Group \\ +OTA Guide Stars \\ +Science OTA stats \\ +Science Cell stats \\ +Science FPA stats +Sky-OTA overlaps \\ +Processed Sky-Cell stats \\ +Calibration 1 input OTA stats \\ +Calibration 1 output OTA stats \\ +Calibration 2 input OTA stats \\ +Calibration 2 output OTA stats \\ +Calibration 3 input stats \\ +Calibration 3 output stats \\ +\hline +\end{tabular} + +\paragraph{Metadata Table Contents} + +Tables NN -- NN list the basic contents of each of the Metadata tables +listed above. + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf weather} \\ +time & \\ +temperature & \\ +humidity & \\ +pressure & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf SkyProbe} \\ +time & \\ +transparency & \\ +error & \\ +Nstars & \\ +astrom & \\ +exptime & \\ +sky & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf LRProbe} \\ +time & \\ +A band & \\ +abs 2 & \\ +abs 3 & \\ +emission 1 & \\ +emission 2 & \\ +emission 3 & \\ +Nstars & \\ +astrom & \\ +exptime & \\ +sky & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf DIMM} \\ +time & \\ +$\sigma_x$ & \\ +$\sigma_y$ & \\ +$fwhm_r$ & \\ +star coords & \\ +exptime & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf NIR} \\ +time & \\ +sky.brightness & \\ +sky.varience & \\ +astrom & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Dome Status} \\ +time & \\ +Az & \\ +open.status & \\ +lights.status & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Telescope Status} \\ +time & \\ +guide.status & \\ +Alt & \\ +Az & \\ +RA & \\ +DEC & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Raw FPAs} \\ +coords & \\ +filter & \\ +exposure status & \\ +exptime & \\ +airmass & \\ +obsgroup ID & \\ +observer & \\ +program & \\ +NOTAs & \\ +NX, NY \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Raw OTAs} \\ +Nx & \\ +Ny & \\ +Ncell & \\ +ID & \\ +temps & \\ +astrom & \\ +NCells & \\ +NX, NY & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Raw Cells} \\ +astrom & \\ +valid & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Observation Group} \\ +ID & \\ +Nimages & \\ +type & \\ +status & \\ +etc & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf OTA guide stars} \\ +OTA ID & \\ +Guide Star ID & \\ +X, Y & \\ +RA, DEC & \\ +$\sigma_{x}$, $\sigma_{y}$ & \\ +$\Delta X_{max}$, $\Delta Y_{max}$ & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Science OTA stats} \\ +OTA ID & \\ +state & \\ +major frame & \\ +obsgroup & \\ +P1 astrom & \\ +P2 astrom & \\ +P3 astrom & \\ +Nguide stars & \\ +bias correction method & \\ +bias summary stats (mean, params, sigma of residuals, biassec) & \\ +applied flat-field image & \\ +kernel convolution parameters & \\ +flat-field summary stats (sigma of sky) & \\ +applied mask image & \\ +masking algorithm & \\ +fringe model images & \\ +fringe correction stats (fringe amplitude, sky sigma) & \\ +object detection stats (nobject, depth, other input params) & \\ +updated astrom params & \\ +astrometry stats (nstars, $sigma_x$, $sigma_y$) & \\ +applied reference catalog & \\ +updated photom params & \\ +photom stats (nstars, $sigma_m$) & \\ +applied reference catalog & \\ +PSF stats & \\ +OTA state & \\ +software versions & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Science Cell stats} \\ +bias summary stats (mean, params, sigma of residuals, biassec) \\ +P1 astrom & \\ +P2 astrom & \\ +P3 astrom & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Science FPA stats} \\ +FPA ID \\ +state \\ +P1 updated astrom params \\ +P1 astrometry stats (nstars, $\sigma_x$, $sigma_y$) +P1 applied reference catalog \\ +P1 software versions \\ +P1 bright stars in field pointer \\ +P1 location of ghosts pointer \\ +P1 large astronomical objects pointer \\ +P1 PSF model & \\ +P3 updated astrom params \\ +P3 astrometry stats (nstars, $sigma_x$, $sigma_y$) +P3 applied reference catalog \\ +P3 updated photom params \\ +P3 photom stats (nstars, $sigma_m$) +P3 applied reference catalog \\ +P3 PSF stats \\ +P3 software versions \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Sky-OTA overlaps} \\ +OTA ID & \\ +Sky Cell & \\ +state & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{1}{l}{\bf Processed Sky-Cell stats} \\ +input OTAs & \\ +PSF adjustments & \\ +CR rejection stats & \\ +image combination parameters & \\ +different image parameters & \\ +average reference image depth / weight & \\ +difference image object detection stats (nobject, depth, other input params) & \\ +summed image object detection stats (nobject, depth, other input params) & \\ +software versions & \\ +processing time / stats & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Calibration 1 input OTA stats} \\ +OTA ID & \\ +output detrend image ID +state & \\ +accepted? & \\ +image stats (counts, exptime, airmass) & \\ +residual stats (mean, sigma, clipped sigma) & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Calibration 1 output OTA stats} \\ +output detrend image ID & \\ +data type (bias | dark | flat) & \\ +Naccepted input images & \\ +Nrejected input images & \\ +summary stats & \\ +normalization reference & \\ +applicability time period & \\ +software versions & \\ +processing time / stats & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{1}{l}{\bf Calibration 2 input OTA stats} \\ +OTA ID & \\ +output detrend image ID +state & \\ +accepted? & \\ +image stats (counts, exptime, airmass) & \\ +residual stats (mean, sigma, clipped sigma) & \\ +applied reduction & \\ +applied reduction params & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{1}{l}{\bf Calibration 2 output OTA stats } \\ +ID & \\ +data type (bias | dark | flat) & \\ +Naccepted input images & \\ +Nrejected input images & \\ +summary image stats & \\ +normalization reference & \\ +applicability time period & \\ +software versions & \\ +processing time / stats & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{1}{l}{\bf Calibration 3 output metadata } \\ +input image stack & \\ +input image stats & \\ +input object summary stats (nobject, density, etc) & \\ +object rejection criteria & \\ +relphot stats (Mcal, dMcal, Klam, etc, bin size) & \\ +residual stats & \\ +output image params (size, etc) & \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{1}{l}{\bf Astrometric Reference Generation output metadata } \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{1}{l}{\bf Photometric Reference Generation output metadata } \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Reference Data} \\ +\hline +\end{tabular} + +\begin{tabular}{ll} +\hline +\multicolumn{2}{l}{\bf Configuration Data} \\ +\hline +\end{tabular} + +\paragraph{Metadata Queries} + +\subsubsection{Object Database} + +The IPP Object Database (IOD) acts as a repository for data on all +astronomical objects. This database is required to provide organized +access to objects on the sky, including the access to the photometry +associated with specific input images, moving objects associated with +specific OTA images. Detailed requirements for the IOD are described +in the IOD subsystem specification document xxx-xxx-xxxx. + +Reference Astrometry Catalogs: +USNO-B +2MASS +HST-GSC +Tycho +etc? + +\paragraph{Object DB Tables} + +\begin{tabular}{l} +\hline +\multicolumn{1}{l}{\bf Object DB Tables} \\ +Images \\ +Objects \\ +Detections \\ +NonDetections \\ +Filters \\ +Photcodes \\ +Bright Objects \\ +Region Tables \\ +Average Magnitudes \\ +USNO Objects \\ +Reference Objects \\ +\hline +\end{tabular} + +\paragraph{Object DB Table Contents} + +\paragraph{Object DB Queries} + +\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. + +\paragraph{Components} + +The Controller consists of N components: the Controller daemon, the +remote clients, and the user clients. + +The Controller daemon maintains a table of processing nodes available +to it and the status of those nodes. When the controller daemon +starts, it attempts to launch a remote client on each of the available +processing nodes. Processing nodes which are not responsive are +placed into an inactive state and retried occasionally. + +The Controller daemon also maintains three tables of processing jobs: +pending jobs, active jobs, and completed jobs. The pending jobs are +those which have not yet been performed. The active jobs are those +currently being performed on one of the remote nodes. The completed +jobs are those which have finished, either successfully or with an +error state. The Controller daemon monitors the collection of remote +clients and sends them new pending jobs when they become free. + +\paragraph{Remote Clients} + +The remote clients communicate with the Controller daemon via a socket +connection. They execute jobs upon request by the controller. A job +is executed in the UNIX user space, and is run as a fork by the remote +client. The remote client must monitor the standard error and +standard output of the job and save them in separate buffers. If the +process dies, the remote client must detect the crash. The remote +client must respond to various commands from the controller daemon. +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 +remote client will return the complete contents of the stdout buffer +via a buffered write and flush the buffer when it is finished. The +remote client will not accept more data on the stdout buffer from the +current job until the send is complete and the buffer is flushed. The +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 +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 +running, it should be killed before the job is cleared. + +{\bf \em start job [command]} execute the given command. The command +should be a standard unix command without command line redirection or +backgrounding. + +\paragraph{User Clients} + +The user clients send commands and jobs to the controller. The user +clients interact with the Controller daemon via a socket. The user +clients, which may be subsystems external to the Controller, interact +with the Controller daemon via the socket connection using a defined +set of commands. The user clients can send new jobs to the controller +daemon, monitor the current job tables, obtain status information on +the completed jobs, change the list of available processing nodes, and +send kill commands for specific jobs to the remote clients. + +{\bf \em new job} The new jobs are sent to the controller in the form +of UNIX commands, along with optional specified processing nodes. If +the processing node is not specified, then the controller will select +a node as one becomes available. + +{\bf \em kill job} The user client may kill an existing +job. \tbd{allow clients to kill jobs sent by other clients? how does +the client specify the job to be killed? is this a necessary +function?} + +{\bf \em get status} The user client may request the current status of +the controller, including the list of pending, active, and completed +jobs and the status of the individual jobs. + +\subsubsection{Scheduler} + +The IPP Scheduler is responsible for coordinating the IPP subsystems +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 +requests to the PTS, including required flat-field images, flat-field +correction observations, or other specialized observations needed to +improve the calibrations. The Scheduler must balance the need for +improved calibrations with the need to process the science images in a +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}. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\subsection{Analysis Stages} + +\subsubsection{Overview} + +\paragraph{Science Image Pipelines} + +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. + +\paragraph{Calibration Image Pipelines} + +The IPP Calibration Image Pipelines perform the tasks needed to +generate high-quality calibration images from the input image +dataset. These operations may be performed on whatever timescales are +appropriate and necessary to maintain the quality and relevance of the +calibration images. There are four distinct types of calibration +image pipelines: the basic detrend creation pipeline, the photometric +correction image creation pipeline, the fringe pattern generation +pipeline, and the sky foreground pattern generation pipeline. + +\paragraph{Reference Catalog Pipelines} + +The IPP reference catalog pipelines use the data in the IPP Internal +Database and the IPP Object Database to determined improved +astrometric and photometric calibration references. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\subsubsection{Phase 1 : image processing preparation} + +Phase 1 : image processing preparation + +The Phase 1 system operates on data from each FPA to calculate basic +astrometric information needed by other stages of the analysis. The +analysis includes: + +\begin{itemize} +\item preliminary astrometry based on the guide-star centroids +\item sky-cell / detector-cell overlaps +\end{itemize} + +The input to this analysis is the list of guide-star pixel centroids +and their celestial coordinates as saved in the metadata database, as +well as the FPA and OTA organization and geometry, and the basic +optical distortion for the camera. For the sky-cell / detector-cell +overlaps, the sky tiling scheme is required. + +The output consists of calculated astrometric parameters (linear +transformation + static distortion) for each of the FPA OTAs. On the +basis of this astrometry, the overlap between the OTAs and the +sky-cells is calculated. The output of this calculation is a list of +sky-cell / OTA links in a database table. This list of links can be +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} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\subsubsection{Phase 2 : image reduction : new version} + +\tbd{how long are processed images kept?} + +\tbd{what subsystem deletes processed images?} + +\tbd{does 'remove' mean 'mask' or 'replace'} + +\tbd{what is the absolute astrometry accuracy at phase 2? 0.1 arcsec +== 0.33 pix?} + +\begin{figure} +\begin{center} +\resizebox{8cm}{!}{\includegraphics{pics/phase2.ps}} +\caption{ \label{phase2} Phase 2 dataflow} +\end{center} +\end{figure} + +\paragraph{Phase 2 Concept} + +Phase~2 processing within the Pan-STARRS 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, +and so each can be run on a single node from start to finish. + +Prior to Phase~2, the Phase~1 process operates on an entire telescope +Focal Plane Array to set the boresight astrometric solution using +the guide stars and initial masking of ghost reflections. + +Phase~2 consists of the following tasks: +\begin{enumerate} +\item Form OT kernel; +\item Convolve de-trend images with the OT kernel; +\item bias / dark / Overscan subtraction; +\item Trim; +\item Non-linearity correction; +\item Flat-field; +\item Subtract sky; +\item Identify CRs by morphology; +\item Find objects in the image; 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. + +\paragraph{Form OT Kernel} + +The first task 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 +used to convolve by. The output is the OT convolution kernel. + + +\paragraph{Convolve de-trend images} + +This task 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 appropriate dark frame --- from the IPP Pixel Server; +\item The appropriate flat-field --- from the IPP Pixel Server; +\item The appropriate fringe frame(s) --- from the IPP Pixel Server; and +\item The appropriate static bad pixel mask --- from the IPP Pixel Server. +\end{enumerate} + +The task 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: +\begin{enumerate} +\item The convolved flat-field; +\item The convolved fringe frame(s); and +\item The updated pixel mask. +\end{enumerate} +Each of these will be used for a later task. + + +\paragraph{Overscan Subtraction} + +This task 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 overscan and physical detector regions --- from the +Metadata; and +\item Detector characteristics (gain, read noise) --- from the +Metadata. +\end{enumerate} + +The overscan is averaged (either in bulk, or individually by rows) or +fit with a polynomial, and the result is subtracted from the image. +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: +\begin{enumerate} +\item The overscan-subtracted object image; and +\item The updated pixel mask. +\end{enumerate} +These will be used for a subsequent task. + +\paragraph{Trim} + +This task 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: +\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 +\item The dimension of the OT convolution kernel in each direction. +\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. + +\paragraph{Non-Linearity Correction} + +This task 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 detector non-linearity correction coefficient(s) --- from +the Metadata. +\end{enumerate} + +The task 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. + +\paragraph{Flat field} + +This task corrects the object image for variations in sensitivity over +the image. The inputs are: +\begin{enumerate} +\item The object image corrected for non-linearity; +\item The corresponding pixel mask; and +\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 +that are non-positive in the flat-field. The outputs are: +\begin{enumerate} +\item The flattened object image; and +\item The updated pixel mask. +\end{enumerate} +Both of these will be used in later tasks. + +\paragraph{Subtract sky} + +This task subtracts the sky background from the object image. The +inputs are: +\begin{enumerate} +\item The object image --- from the previous task; +\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 +objects on the image using the astrometric solution from the +boresight, and fits for the sky background, consisting of a polynomial +to model the continuum, and the fringe frame(s) to model the fringes +from sky emission lines. If the concentration of objects in the image +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. + +\paragraph{Identify CRs by morphology} + +This task identifies cosmic rays (or other hot pixels missed in the +static bad pixel mask) on the basis of their morphology. The inputs +are: +\begin{enumerate} +\item The object image; and +\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 +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. + +\paragraph{Find objects} + +This task 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 +register images from different focal planes. The output is the +catalogue of objects (see Appendix~\ref{ap:catalogues}) identified on +the image, which is sent to the metadata database, associated with the +object image. + +\paragraph{Bright object postage stamps} + +This task 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: +\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 +instrumental magnitude, along with corresponding pixel masks. The +outputs are these postage stamps and pixel masks, which are sent to +the IPP Pixel Server. + +\paragraph{Metadata} + +The following metadata associated with the images are required for +Phase~2 operation: +\begin{itemize} +\item The orthogonal transfer (OT) image shifts made during the +exposure --- in order to create a convolution kernel; +\item Time of observation --- for selecting the appropriate detrend +images; +\item Filter --- for selecting the appropriate detrend images; +\item Telescope identification --- for selecting the appropriate +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 read noise --- for calculating photometric errors and +determining the quality of the overscan; +\end{itemize} + +\paragraph{Pixel Masks} +\label{ap:masks} + +This section describes the requirements on Bad Pixel Masks (BPMs). +These will consist in of bit masks for each pixel. For Phase 2, flags +are required for at least each of the following pixel attributes: +\begin{enumerate} +\item The pixel is a charge trap; +\item The pixel is a bad column; +\item The pixel is saturated in the A/D converter; +\item The pixel is non-positive in the flat-field; +\item The pixel is part of a row that has excess noise; and +\item The pixel is determined to be a cosmic ray, based on its +morphology. +\end{enumerate} + +Of these, only masks for the charge traps need to be grown by the +extent of the OT convolution kernel. For other pixel types, +orthogonal transfer of the flux in this pixel will not (necessarily) +affect the flux in neighbouring pixels + +\paragraph{Object Catalogues} +\label{ap:catalogues} + +Object catalogues from Phase 2 shall consist of at least the +following elements for each object: +\begin{enumerate} +\item Object centre, with corresponding errors; +\item Object magnitude, with corresponding error; +\item Object isophotal magnitude, with corresponding error; +\item Object FWHM; +\item Object elliptical axis lengths; and +\item Object position angle for ellipse. +\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 + saved as a single MEF file. how to handle this difference?} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\subsubsection{Phase 3 : exposure analysis} + +\begin{figure} +\begin{center} +\resizebox{8cm}{!}{\includegraphics{pics/phase3.ps}} +\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: + +\begin{itemize} +\item improved astrometric solution based on comparison between + objects in the images and the astrometric reference. +\item improved background model based on the full telescope field, or + fields. +\item photometric solution based on comparison to photometric + standards +\item PSF convolution kernels to transform images to a common PSF. +\end{itemize} + +In the Phase 2 analysis, the astrometric solutions were determined +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 ??? + +\tbd{what is the expected accuracy of the relative astrometric + solution compared to the absolute astrometric solution?} + +\tbd{for image combination in phase 4, should we use relative + astrometry to map N-1 images to 1, or are we sufficiently accurate + to use absolute astrometry to map N images to the sky-cells?} + +In the Phase 2 analysis, the background is determined based only on +the available sky in a single OTA image. However, the background +structures are normally correlated on the scale of the FPA, so an +improved background solution can be determined by combining the +information from many OTA images. \tbd{is the background correlated +between FPAs?} + +\tbd{Phase 3 photometric improvement??} \tbd{Phase 3 determined +accurate relative photometry between the N images which are to be +combined in the Phase 4 analysis. Is this more accurate than the +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. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\subsubsection{Phase 4 : image combination} + +\begin{figure} +\begin{center} +\resizebox{8cm}{!}{\includegraphics{pics/phase4.ps}} +\caption{ \label{phase4} Phase 4 dataflow} +\end{center} +\end{figure} + +\paragraph{Phase 4 Concept} + +Phase 4 processing within the Pan-STARRS 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. + +Prior to Phase 4, the Phase 3 process produces the following products: +\begin{itemize} +\item bias-subtracted, flattened, sky-subtracted images; +\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: +\begin{enumerate} +\item Combine Images; +\item Identify Sources; +\item Transient Identification; and +\item Add to Static Sky. +\end{enumerate} +These tasks are each explained below. + +\paragraph{Combine Images} + +The first task 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: +\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 photometric calibration (zeropoint) for each image --- from +Phase 3; and +\item a (relative) weighting for each image proportional to the +signal-to-noise (i.e.\ sky noise divided by the square of the seeing) +--- from metadata associated with the images. +\end{enumerate} + +The task 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: +\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; +\item Limiting magnitude of the combined sky cell image --- metadata +associated with the combined sky cell image, and used for a later task +in Phase 4; and +\item Catalogue of sources on the combined sky cell image --- sent to +the IPP Object Database. +\end{enumerate} + + +\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} + +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 +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 +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. + +The subtracted image is scoured for point sources above the noise +threshold, as well as short and long streaks caused by asteroids and +satellites, respectively. It may be neccessary to determine whether +the detection is false by virtue of its PSF (a cosmic ray missed by +the combination script should have a very narrow PSF, at least in one +dimension), or negative pixels surrounding a positive core (caused by +a bad subtraction, in turn caused by a bad kernel). + +If the subtraction is very bad (many false detections), then Phase 4 +for this sky cell should fail neatly, with a flag for the human +supervisor. Otherwise, all variable sources identified in the +subtracted image should be masked in the combined sky cell image. The +pixels from the combined sky cell image for point sources and short +trails (asteroids) should be saved (say, 3 $\times$ FWHM in radius +surrounding the source, configurable). The long trails (satellites) +should be removed in the combined sky cell image and the subtracted +image, from edge to edge. The dividing limit between short and long +trails shall be a configurable parameter, initially set to 15 degrees +per day. + +The task outputs: +\begin{enumerate} +\item Combined sky cell image, with all variable sources masked --- +used for the next task; +\item Subtracted image, with long trails masked --- sent to the IPP +Pixel Server; and +\item Catalogue of variable sources --- sent to the IPP Object +Database. +\end{enumerate} + + +\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: +\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, +or the IPP Pixel Server; and +\item Relative weightings, based on the relative signal-to-noise in +each of the images --- estimate made from metadata associated with +each image. +\end{enumerate} + +The sky cell image is added to the static sky. The sky cell image +should already be photometrically accurate (when combined), and +variable sources have been masked, so it is safe to simply add the +images, employing the weightings. Sources should be identified on the +new static sky, and the limiting magnitude of the new static sky image +estimated. + +The output is: +\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 estimated limiting magnitude for the new static sky --- +metadata associated with the the new static sky image. +\end{enumerate} + +\paragraph{Notes} + +\begin{itemize} +\item Catalogues should include positional information ($x,y$, with +associated errors), photometry (with associated error), and shape +parameters (FWHM, major and minor axes, position angle). +\item Limiting magnitudes can be obtained by photometering many +regions of blank sky (if possible), and (robustly) estimating the mean +and standard deviation (in counts). The limiting magnitude is the +magnitude corresponding to 3 (configurable) standard deviations above +the mean. +\end{itemize} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\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. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\subsubsection{fringe pattern and sky foreground model creation} + +The fringe model creation and sky foreground model creation pipelines +use night-sky images with sufficient flux to measure the fringe or sky +models. The input images are processed and optimally combined to yield +a set of correction fringe patterns. The fringe pattern creation and +the sky foreground pattern creation have a similar processing +structure: both require processing of the input images, both determine +a set of principal components as a function of specific input +parameters. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\subsubsection{photometric flat correction image creation} + +The photometric flat-field correction uses images which have been +dithered with a large range of spatial scales, combined with the +uncorrected flat-field images, to generate a correction to the +flat-field image. This correction compenstates for non-uniform +illumination of the detector during the initial flat-field generation +stage. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\subsubsection{Astrometric Reference Catalog} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\subsubsection{Photometric Reference Catalog} + +\subsection{Modules} + +\subsection{PanSTARRS 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 +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 +IOD. The scheduler creates input processing configuration files for +the processing pipelines and queries the IID and IPS and pushes +results back to the IIS. + +FITS Images + +FITS Tables + +XML + +SQL queries + +C:DB interactions + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\subsection{External Interfaces} + +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. + +\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 +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 +time scales. The IPP scheduler sends telescope schedule requests to +the PTS. + +\subsubsection{Published Static Sky Server} + +The Static Image Server provides segments of the current static sky +image to the IPP on demand. IPP subsystems which require this data +will block until it is available or timeout if it is not. The IPP +provides updated static sky images to the SIS when available. + +\subsubsection{Published Object Database} + +The Master Science Object Database receives new object photometry from +the IPP. The IPP IOD acts as a cache for object photometry data; +\tbd{an IPP subsystem will send photometry data in batches on some +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{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 +much data?} + +\subsection{Computer Hardware} + +\subsubsection{Overview} + +This document discusses the likely range of the Pan-STARRS Image +Processing Pipeline (IPP) hardware requirements. The hardware +requirements addressed in this document consist of: + +\begin{itemize} +\item Total Disk Volume +\item Total Processing Power +\item Sustained Switch Bandwidth +\item Sustained Node Network I/O +\item Sustained Disk I/O +\end{itemize} + +Even without the complete IPP design, it is possible to identify the +major drivers on the hardware requirements. The total disk volume +requirements are dominated by the need to store raw images for a +certain period, the need to store calibration images for a longer +period, and the need to store the static sky images. Of the various +analysis pipelines, and depending on the data organization as +discussed below, Phase 2 and Phase 4 present the most significant +demands in terms of data I/O throughput on the network. Phase 2 and +Phase 4 also present the most significant CPU demands. In this +discusion, Phase 2 refers to the per-OTA image pre-processing in which +the instrumental signature is removed and a first pass object +detection is performed. Phase 4 refers to the multiple OTA +combination in which the pre-processed images are merged and combined, +in both addition and subtraction, with the static sky image, and up to +three object detection passes are performed. + +This document does not address the hardware requirements implied by +the Phase 0, 1, or 3 stages, nor the load required by the calibration +image creation stages. In the first instance, the operations are only +performed on the metadata and are extremely minimal both in terms of +data I/O and computation requirements. In the second case, the +processing is less time critical than the per-image processing and is +performed only infrequently (once per night to once per week or +month). This document also does not address any hardware requirements +introduced by the metadata manipulation. The software implementation +for metadata storage (RDBMS, FITS tables, etc) will have a very large +impact and will be evaluated along with the needed hardware at a later +date. + +\subsubsection{Scenarios} + +We will address the various hardware requirements by referring to a +set of data processing and data organization scenarios. The actual +hardware requirements will depend on design decisions which are not +yet available. It is possible to define the data organization in ways +which will minimize the hardware requirements, but which will increase +the software development effort. We will discuss both the worst-case +data organization scenario, which does not require significant +intelligence in the software systems, and the optimal data +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 +based on the Design Reference Mission [REF]. + +The IPP hardware system must provide both data storage and +computational resources. The IPP requires relativley 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. The first +assumption we make is that the hardware is organized into nodes which +provide both data storage and computational resources. The second +assumption we make is that the data storage nodes are divided into two +classes: those which deal with the per-OTA data and those that provide +the static sky storage. In addition, we assume that 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 used in this configuration; although it is +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 +system. In such a case, the interswitch communication must also meet +the required throughput needs. We discuss the hardware requirements +in the assumption that such an organization will be necessary. + +The way in which the images are distributed among the storage and +compute nodes will largely determine the I/O bandwidth requirements. +For data bandwidth requirements calculations, it is necessary to make +some assumptions about the data organization. For the purposes of +this document, we explore two extreme-case options: +\begin{itemize} +\item Random Data Distribution - OTA \& Sky data is randomly + distributed within the compute node of a given type (ie, OTA data is + randomly distributed among the OTA compute nodes). +\item Optimal Data Distribution - OTA \& Sky data is optimally + distributed to compute OTA/Sky nodes (OTA processing is always on a + machine with local OTA data). +\end{itemize} +A second factor which will have a significant impact on the I/O +requirements is the image storage format for the processed and +calibration images. We have two basic choices: 32 bit floating point +format or 16 bit integer format with appropriate scaling. In the +former case, additional dynamic range is retained, while in the latter +case, we reduce the data volume by a factor of 2. While some may +argue that the higher dynamic range is necessary, arguments can be +made that the 16 bit range is sufficient. (In particular, the 16 bit +data provides a dynamic range far above the expected 1/1000 fractional +accuracy of the flat-field images). A related question is the number +of calibration images needed by the processing system. Since the +complete analysis is not yet defined, this number is difficult to +ascertain. However, we can make a range of assumptions which are +reasonable. We therefore adopt two data volume scenarios to explore +these possibilites: +\begin{itemize} +\item Standard Data Volume - 32 bit data for processed and calibration + images, average of 7 calibration frames per image. +\item Minimal Data Volume - 16 bit data for processed and calibration + images, average of 4 calibration frames per image. +\end{itemize} +In the discussion that follows, we explore the hardware requirements +implied by the collection of four combinations of these two sets of +scenario options. + +\begin{table} +\begin{center} +\caption{Hardware Throughput Tests \label{existing-hardware}} +\begin{tabular}{lrrrr} +\hline +\hline +Test & where \& when & model & result \\ +\hline +node I/O & CFHT 11/2002 & Intel 1000 Gigabit & 35 - 40 MB/s sustained \\ +node I/O & CFHT 2/2004 & Intel 1000 Gigabit & 65 - 70 MB/s sustained \\ +RAID write & CFHT 2/2004 & 3ware RAID cntl + IDE & 110 MB/s sustained \\ +Switch Load & VeriTest & Cisco & 3 GB/s (for 32 ports) \\ +\hline +\end{tabular} +\end{center} +\end{table} + +\subsubsection{Existing Hardware Throughput} + +We have collected a few representative tests of various pieces of +modern hardware to give a reference for the throughput capabilities. +A number of hardware configurations have been tested at CFHT for the +Elixir project, and we include here their recent reported hardware +RAID-5 I/O speeds and GigE card speeds. We also have included data +from VeriTest studies of Cisco switch throughput, commissioned by +Cisco for a 32 port GigE switch. These tests are summarized in +Table~\ref{existing-hardware}. + +\begin{table}[b] +\begin{center} +\caption{Data Storage Requirements \label{storage}} +\begin{tabular}{lrrrr} +\hline +\hline + & Standard / PS-4 + & Standard / PS-1 + & Minimal / PS-4 + & Minimal / PS-1 \\ +\hline +Raw data & 300 TB & 75 TB & 300 TB & 75 TB \\ +static sky & 512 TB & 64 TB & 256 TB & 32 TB \\ +calibration frames & 175 TB & 18 TB & 17 TB & 5 TB \\ +metadata db & 2 TB & 2 TB & 0.2 TB & 0.2 TB \\ +object db & 60 TB & 4 TB & 60 TB & 4 TB \\ +\hline +totals & 1050 TB & 163 TB & 633 TB & 116 TB \\ +\hline +\end{tabular} +\end{center} +\end{table} + +\subsubsection{Data Storage Requirements} + +The Pan-STARRS 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. +We discuss each of these data items and their impact on the data +storage requirements for the IPP, and identify the impact of the +minimal vs standard data storage requirements as well as the +requirements specifically for PS-1. Table~\ref{storage} summarizes +the data storage requirements in the different scenarios. + +\paragraph{Raw Data Storage} + +There are two basic image types which will be acquired: night-time +science images and calibration images. The night-time science images +consist of 1Gpix per image, or 2GB in raw format. At nominal cadence, +the 4 telescopes can obtain images at a sustained rate of 1 image per +30 seconds per telescope for the entire night of 10 hours (36000 +minutes). A total of 100 calibration images per night would be a +substantial overestimate of the typical expectation. Combining these +numbers, we can expect to receive a total of 1300 image per telescope +per night, 5200 image total, or 10.4 TB of data per night. The total +data storage requirements for the raw data are governed by the number +of nights' worth of data we are required to keep online. A reasonable +number is one month to allow a full moon's cycle. Thus, for raw image +storage, we require a total of 300 TB data storage. For PS-1, this +number is simply scaled down by a factor of 4. The choice of the +minimal data volume does not affect these numbers because the raw data +is already stored with 16 bit pixels. ({\bf note: the PS-1 design +reference may now require storage of the entire first year of data, +calculated to be 200 TB}). + +\paragraph{Static Sky Data Storage} + +The static sky is represented by images with 0.2 arcsec per pixel. +There will be one summed image and one weight image for each of the 6 +filters, each stored in floating point format. At this resolution, +there are 324 Mpix per square degree, and we will observe a potential +total area of 30,000 square degrees. Allowing for 10\% overage for +overlapping tiling, we require a total of 10.7 Gpix to cover the sky +once, or a total of $\sim 512$ TB for the static sky images. In the +minimal data volume scenario, this value is reduced by a factor of 2, +while in PS-1, the reduction is a factor of roughly 8 because we only +intend to store the static sky for the ecliptic plane survey and the +small IPP verification program ({\bf note: this last point is no +longer valid - the PS-1 static sky may require the entire 3pi}). + +\paragraph{Calibration Frame Storage} + +The possible required calibration frames consist of the bias, dark, +and mask images, along with one flat, one flat-correction, and +multiple sky/fringe library frames per filter. In fact, not all types +are needed at all stages. For the standard data volume, we assume an +average of 7 calibration frames per image and filter. This results in +a total of 42 master calibration image per telescope. If we intend to +keep all master calibration frames for the project lifetime, and +generate a new master on a weekly basis (a reasonable time-scale), +then we can expect to require a total of 175 TB of calibration image +by the end of the 5 year lifetime of the project. For the case of +PS-1, the time period is only 2 years, and there is only 1 telescope, +resulting in a factor of 10 reduction in the volume. For the minimal +data case, we reduce the volume by another factor of 3.5. We also note +that this is likely to be a drastic overestimate as we are unlikely to +need to regenerate all master calibration frames on a weekly +time-scale. + +\paragraph{Metadata Database Storage} + +The metadata data storage requirements are driven by the need to store +the data for the project lifetime. There are two types of metadata +generated at the summit: data associated with images and environmental +data. The environmental data consists of measurements on a regular +cadence, roughly 1 per minute, of a variety of parameters. We suggest +an expected of 1kB per entry, for a total of 2.6 GB over the lifetime +of the project. PS-1 will represent a smaller amount of data per +minute, and also a factor of 2.5 fewer minutes. We suggest PS-1 may +have a total environmental metadata set smaller by a factor of 5. The +additional systems, such as the DIMM, SkyProbe, NIR Sky Camera, and +the LRProbe will have higher data requirements, but should be +considered as separate, self-contained systems. Their data products +are distilled to a limited number of parameters per minute which are +included in the 1kB given above. Furthermore, items such as +guide-star history, if saved, will be saved with the image data and +represents only a small fraction of the total image data volume. Some +subset of the telescope diagnosic information may be a high volume +data product as well, but only retained by the telescope control +system for the purpose of diagnostic studies. Such data will be +excluded from this analysis. + +The image metadata consists of values associated with the FPA (4), the +OTAs (240), and the Cells (15360). Aside from the guide star history, +the total data requirements for each of these entries will be scaled +by the number of bytes required for the metadata from each data level. +Clearly, if the Cell entry is allowed to be large, it will dominate +the total Metadata data volume. If we suggest an expected number of +64 bytes per Cell, 256 B per OTA, and 1k per FPA, we find a total +metadata volume per exposure of roughly 1 MB, completely dominated by +the Cell metadata. With the exposure rates above, we find a total of +metadata volume of 1.8 TB over the lifetime of the project. For PS-1, +the total volume is reduced by a factor of 2.5 (for the shorter +lifetime) and another factor of 4 (for the lone telescope). Neither +data quantity is affected by the minimal vs standard data volume +choice. + +\paragraph{Object Database Storage} + +The hardware requirements for the IPP object database are rather +flexible: the total volume depends critically on the depth to which +the object detection analyses are performed (and thus the total number +of object detections) and the number of object parameters which are +measured. We can make very rough estimates that the total number of +detections over the 5 year lifetime of the project may be in the +vicinity of $5\times10^{11}$. We can conservatively estimate the +number of bytes needed to represent each detection as 128 B, resulting +in a total data storage for the object detections of 60 TB. However, +this number depends strongly on the timescale for which the IPP is +required to maintain all object detections, and may potentially be +significantly reduced. For the case of PS-1, the total number of +detections is likely to be reduced by a factor of 4 for the number of +telescopes, and potentially another significant factor ($\sim 4?$) by +limiting the depth of object detections. Again, the minimal data +volume scenario is irrelevant to the object database volume. + +\subsubsection{CPU Requirements} + +Phase 2 and Phase 4 dominate the processing requirement, primarily +because they must keep up with the image delivery rate of 1 per 30 +seconds. We have performed benchmarks of a demonstration version for +both the Phase 2 and Phase 4 analyses. + +For the Phase 2, a substantial fraction of the processing time is +consumed by the need to perform FFTs on the images in order to +convolve them with the guide-star kernel, and in the smoothing used +for the object detection process. Additional processing time is +needed by the object detection, deblending, and analysis. Experiments +with the FFTW package show that FFTs may be performed on Intel +processors at rates of approximately 0.25 GHz-sec / Mpix for data sets +of order 1 Megapixel. The FFTs required for the Phase 2 analysis are +performed on the 512$^2$ pixel cells, so these numbers may roughly be +scaled linearly to determine the total time required for OTA +processing. A single FFT on a full OTA, with 64 Cells, therefore +requires roughly 4 GHz-sec. For the full Phase 2 analysis, there are +roughly 4 single direction FFTs required excluding those associated +with object detection; thus the total processing time for these FFTs +is approximately 16 GHz-sec. The addtional analysis steps, excluding +object detection and characterization, account for a small fraction of +this compute time, which we estimate at 10\%. The object detection +stage depends somewhat on the depth to which the analysis is +performed, and the number of measurements made per object. Typical +analysis performed by the Sextractor routine, which performs a +substantial number of per-object analyses, requires 27 GHz-sec for a +full OTA, including the FFTs used for smoothing. We can therefore +assume a total of 50 GHz-sec per OTA for the Phase 2 processing. This +converts to a total of 12000 GHz-sec for a complete major frame. + +For Phase 4, the main computational tasks are combining the multiple +images, with cosmic-ray rejection, and performing the object detection +tasks. Nick Kaiser has done tests of the Phase 4 image combine and +rejection stages, and finds a total processing time of roughly 96 +GHz-sec for a full stack of 4 OTA images. If we add in an additional +34 GHz-sec for detailed object detection and image differencing, we +find a conservative estimage of 130 GHz-sec for a 4-image OTA stack, +equivalent to 7800 GHz-sec for a major frame. + +For PS-1, the data processing will clearly require a smaller amount of +computational resources because of the lower image rate. However, the +total number of GHz-sec required for the complete analysis of 4 input +images and the combination with the static sky will remain +more-or-less the same. Some reduction in the load may be gained by +reducing the complexity and depth of analysis for PS-1. Depending on +the details and depth of the analysis, we may reduce the computational +load by a factor of 2. + +\begin{table} +\begin{center} +\caption{Data Scenarios (MB per OTA or Sky-cell) \label{scenarios}} +\begin{tabular}{lrrrr} +\hline +\hline + & Random / Standard & Random / Minimal & Optimal / Standard & Optimal / Minimal \\ +\hline +{\em Phase 2 input} & & & & \\ +from summit & $2 \times 32$ MB & $2 \times 32$ MB & $2 \times 32$ MB & $2 \times 32$ MB \\ +input image & 32 MB & 32 MB & {\bf 32 MB} & {\bf 32 MB} \\ +calibration & $7 \times 64$ MB & $4 \times 32$ MB & {\bf 7 $\times$ 64 MB} & {\bf 4 $\times$ 32 MB} \\ +mask image & 16 MB & 8 MB & {\bf 16 MB} & {\bf 8 MB} \\ +\hline +network I/O: & 560 MB & 232 MB & 64 MB & 64 MB \\ +disk I/O: & (560 MB) & (232 MB) & 496 MB & 168 MB \\ + & & & & \\ +{\em Phase 2 output} & & & & \\ +output image & 64 MB & 32 MB & {\bf 64 MB} & {\bf 32 MB} \\ +output mask & 16 MB & 8 MB & {\bf 16 MB} & {\bf 8 MB} \\ +image to P4 & $1.5 \times 4 \times 64$ MB & $1.5 \times 4 \times 32$ MB & $1.5 \times 4 \times 64$ MB & $1.5 \times 4 \times 32$ MB \\ +mask to P4 & $1.5 \times 4 \times 16$ MB & $1.5 \times 4 \times 8$ MB & $1.5 \times 4 \times 16$ MB & $1.5 \times 4 \times 8$ MB \\ +\hline +network I/O: & 200 MB & 100 MB & 120 MB & 60 MB \\ +disk I/O: & (80 MB) & (40 MB) & 80 MB & 40 MB \\ + & & & & \\ +{\em Phase 4} & & & & \\ +input images & $1.5 \times 4 \times 64$ MB & $1.5 \times 4 \times 32$ MB & & \\ +input masks & $1.5 \times 4 \times 16$ MB & $1.5 \times 4 \times 8$ MB & & \\ +static sky & 64 MB & 64 MB & & \\ +static weight & 64 MB & 32 MB & & \\ +\hline +input: & 608 MB & 336 MB & & \\ +output: & 192 MB & 128 MB & & \\ +\hline +\multicolumn{5}{l}{\em Bold-faced entries are access to local-disk} \\ +\multicolumn{5}{l}{\em parenthesised disk I/O numbers are parallel with the network I/O} \\ +\end{tabular} +\end{center} +\end{table} + +\subsubsection{Per-Node I/O Requirements} + +Data I/O per node is defined as the number of bytes per second passed +through the node's network adapter. The data throughput for each node +depends strongly on the scenarios identified above. In this section, +we identify the data which is passed between nodes for each of the +different scenarios. Table~\ref{scenarios} lists the per-node data +I/O for the four scenarios. + +For PS-4, there are only 30 seconds of compute time allowed for each +of the Phase 2 and Phase 4 analyses. We use the data I/O volumes and +some assumptions about expected network and disk bandwidth to estimate +the I/O and processing timeline for the four scenarios. From this +analysis, we can judge the total CPU requirements in terms of GHz, not +just GHz-sec. We have assumed that GigE network adapters are capable +of delivering data at 50MB/sec sustained and that a disk RAID can +deliver sustained 100 MB/sec reads and writes. These numbers are +conservative estimates based on recent tests discussed above. Using +these assumptions, Table~\ref{throughput} lists the time allocations +for the complete set of scenarios for the case of PS-4. + +\paragraph{Random / Standard Data Scenario} + +In the Random Data Distribution scenario, there is a single CPU +allocated to each OTA in the OTA farm and a single CPU for each Sky +cell process. The OTA data are stored across random machines in the +OTA farm, with the result that every Phase 2 processing requires +network access to the data. For each science OTA image which is +observed, each OTA node will read from the network a total of 560 MB +(the 2 raw images for data storage and the 7 calibration frames, along +with one mask and one raw input image) and write a total of 200 MB +(one processed image and the mask along with the 1.5 processed images +and masks for the Phase 4 analysis). Given the assumption of 50 MB/s +from the network adapter, the total data volume implies an I/O period +of 15.2 seconds. Note that the disk I/O is parallel with the network +I/O and substantially underfills the disk bandwidth. + +\paragraph{Random / Minimal Data Scenario} + +In the Random-Minimal, there is a single CPU allocated to each OTA in +the OTA farm and a single CPU for each Sky cell process, and the OTA +data are stored across random machines in the OTA farm. However, the +calibration and the processed science images are stored at 2 bytes per +pixel, the mask is set at 4 bits per pixel, and only 4 calibration +images are assumed. For each science OTA image which is observed, +each OTA node will read from the network a total of 232 MB (the 2 raw +images for data storage and the 4 calibration frames, along with one +mask and one raw input image) and write a total of 100 MB (one +processed image and the mask along with the 1.5 processed images for +the Phase 4 analysis). Given the assumption of 50 MB/s from the +network adapter, the total data volume implies an I/O period of 6.6 +seconds. Again, note that the disk I/O is parallel with the network +I/O and substantially underfills the disk bandwidth. + +\paragraph{Optimal / Standard Data Scenario} + +In the Optimal Data Distribution scenario, there is a single CPU +allocated to each OTA in the OTA farm and a single CPU for each Sky +cell process. In addition, all data for the specified OTA are stored +on local disks attached to the same computer as the CPU, with the +result that all Phase 2 I/O is made to a local disk. For each science +OTA image which is observed, each OTA node will read from the network +a total of 2 raw images (one for the original image, one for the +backup copy) and write an average of roughly 1.5 processed images and +masks to the Phase 4 machines for a total of 184 MB of network I/O. +During the processing stage, the OTA node will read from disk a total +of 496 MB (7 calibration frames at 64 MB each, one 16 MB mask, and one +raw science image at 32 MB) and write a total of 80 MB (one processed +image at 64 MB and one mask at 8 MB). Given the assumptions for the +network and disk bandwidths (50 MB/s and 100 MB/s respectively), the +data volumes imply a total I/O period of 9.5 seconds. In this +instance, the network I/O is presumed to be sequential with the disk +I/O. + +\paragraph{Optimal / Minimal Data Scenario} + +In the Optimal / Minimal Scenario, the minimal data sizes are used +with the optimal data distribution scheme. In this case, we reduce +the disk I/O volume to 168 read and 40 MB write, and the network +traffic to 124 MB. Given the assumptions for the network and disk +bandwidths, the data volumes imply a total I/O period of 4.6 seconds. +Again, the network I/O is presumed to be sequential with the disk I/O. + +\paragraph{Phase 4 Node I/O Requirements / Standard Data Volume} + +Although it is easy to arrange the OTA data in such a way that the +majority of I/O is performed locally, it is not as easy to arrange +this for the Static Sky data used by the Phase 4 analysis. We +therefore make the assumption that the Phase 4 analysis will require +all input OTA data to be loaded across the network, as well as all +Static Sky data. This is somewhat of an overestimate as some of the +Static Sky data will be processed by machines with the data stored +locally, and clever Static-Sky data organization schemes can enhance +this chance. + +In the Phase 4 analysis, the images from the 4 separate telescopes are +combined into a single image, confronted with the appropriate segment +of the static sky, with output difference image and updated static sky +image. If we restrict input access to the individual OTA cells, the +maximum read overhead is 50\% (need to read a 10x10 set of cells for +an 8x8 input image). If the processing is performed on Static Sky +segments equivalent in size to the OTAs, the input data is 608 MB (384 +MB of processed science image, 96 MB of mask images, 64 MB of static +sky image and 64 MB of static sky weight map) while the output data is +192 MB (static sky, weight map, and difference image, each 64 MB). +Thus, we require a total of 800 MB network I/O. Given the network +bandwidth, this implies an I/O period of 16 seconds for Phase 4. + +\paragraph{Phase 4 Node I/O Requirements / Minimal Data Volume} + +In the minimal data volume scenario, the Phase 4 analysis volume is +significantly reduced. The total volume of input data is 336 MB (192 +MB of processed science image, 48 MB of input mask, 64 MB of static +sky image and 32 MB of static sky weight map) while the output data is +128 MB (64 MB static sky, 32 MB weight map, and 32 MB difference +image). Thus, we require a total of 464 MB network I/O, which implies +an I/O period of 9.3 seconds. + +\begin{table} +\begin{center} +\caption{Data Throughput for 4 Scenarios \label{throughput}} +\begin{tabular}{lrrrr} +\hline +\hline +& +\multicolumn{1}{c}{Random / Standard} & +\multicolumn{1}{c}{Random / Minimal} & +\multicolumn{1}{c}{Optimal / Standard} & +\multicolumn{1}{c}{Optimal / Minimal} \\ +\hline +Phase 2 per-node network I/O & 15.2 s & 6.6 s & 3.7 s & 2.5 s \\ +Phase 2 per-node disk I/O (read) & (5.6 s) & (2.3 s) & 5.0 s & 1.7 s \\ +Phase 2 per-node disk I/O (write) & (0.8 s) & (0.4 s) & 0.8 s & 0.4 s \\ +Phase 2 CPU total & 14 s : 860 GHz & 23 s : 520 GHz & 20 s : 600 GHz & 25 s : 480 GHz \\ +Phase 4 per-node I/O & 16 s & 9.3 s & & \\ +Phase 4 CPU total & 14 s : 490 GHz & 20 s : 390 GHz & & \\ +Phase 2 switch load & 6.1 GB/s & 2.7 GB/s & 1.5 GB/s & 1.0 GB/s \\ +Phase 4 switch load & 0.8 GB/s & 0.5 GB/s & 0.8 GB/s & 0.5 GB/s \\ +Phase 2 to Phase 4 switch load & 1.1 GB/s & 0.6 GB/s & 1.1 GB/s & 0.6 GB/s \\ +Summit to Phase 2 switch load & 0.5 GB/s & 0.5 GB/s & 0.5 GB/s & 0.5 GB/s \\ +\hline +\end{tabular} +\end{center} +\end{table} + +\subsubsection{Switch I/O Requirements} + +The switch I/O requirements are defined by the total number of bytes +per second serviced by the two switches in the system. For the +analysis of the Switch I/O requirements, the choice of data +distribution again has a major impact. We again test the four +scenarios discussed above: Random Data Distribution, Random / Minimal, +Optimal Data Distribution, and Optimal / Minimal. + +\paragraph{Random / Standard Data Scenario} + +In the Random Data Distribution scenario, each OTA node needs to read +a total of 560 MB from the network and write a total of 200 MB every +30 seconds. With 240 OTA nodes, this corresponds to a total bandwidth +of 6080 MB/sec, or 49 Gb/sec. Note that this includes the bandwidth +needed to copy data from the summit and make two copies on the OTA +machines, as well as the bandwidth to send the processed image +portions to the Phase 4 machines. The Phase 4 processing adds an +additional 320 MB of network I/O per Sky-Cell group, and there are +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 +attached to separate switches. An additional bandwidth requirement is +derived by the need to exchange data between these switches in for +Phase 4. The total amount of data exchanged between these switches is +480 MB per Sky-cell, for a total bandwidth of 1120 MB/sec. In +addition, the connection to the summit is a single, separate line +which needs to support the bandwidth requirement of copying all intial +raw images. In our simple model, each raw image is copied twice, +accounting for a total of 15360 MB every 30 seconds, or a bandwidth +load of 512 MB/sec. (Note that this last is double the actual +bandwidth requirement to the summit: a dedicated local circular buffer +would reduce the need for the second copy to come directly from the +summit.) + +\paragraph{Random / Minimal Data Scenario} + +In the Random / Minimal Scenario, the data volumes are significantly +reduced. The total Phase 2 bandwidth contribution is 332 MB over 30 +seconds for 240 nodes (2656 MB/sec) and the residual Phase 4 bandwidth +load is 224 MB per Sky cell over 30 seconds (522 MB/sec). The +inter-switch communication is now 240 MB per sky cell over 30 seconds, +or 560 MB/sec. + +\paragraph{Optimal / Standard Data Scenario} + +In the Optimal Data Distribution, the Phase 2 network bandwidth is +reduced significantly to 184 MB per OTA node, for a total of +1.5GB/sec, while the Phase 4 network bandwidth remains unchanged at +750 MB/sec. The inter-switch communication also remains the same at +1.12 GB/sec. + +\paragraph{Optimal / Minimal Data Scenario} + +In the Optimal / Minimal Scenario, the total Phase 2 network bandwidth +drops to 124 MB per OTA node, for a total of 1.0GB/sec, while the +Phase 4 network bandwidth is 552 MB/sec. The inter-switch +communication remains the same as the Random/Minimal Scenario at 560 +MB/sec. + +\begin{table}[t] +\begin{center} +\caption{\label{NP2} Phase 2 load per major frame (12000 GHz-sec)} +\begin{tabular}{lrrrr} +\hline +\hline +& Random/Standard +& Random/Minimal +& Optimal/Standard +& Optimal/Minimal \\ +\hline +network I/O (GB) & 182 & 80 & 44 & 30 \\ +PS-1 & & & & \\ + I/O (cpu-sec) & 3640 & 1600 & 880 & 600 \\ + CPU (cpu-sec) & 4000 & 4000 & 4000 & 4000 \\ + \# cpus & 64 & 47 & 41 & 38 \\ +PS-4 & & & & \\ + I/O (cpu-sec) & 1820 & 800 & 440 & 300 \\ + CPU (cpu-sec) & 2000 & 2000 & 2000 & 2000 \\ + \# cpus & 127 & 93 & 81 & 77 \\ +\hline +\end{tabular} +\end{center} +\end{table} + +\begin{table}[b] +\begin{center} +\caption{\label{NP4} Phase 4 load per major frame (7800 GHz-sec)} +\begin{tabular}{lrr} +\hline +\hline +& Standard +& Minimal \\ +\hline +network I/O (GB) & 48 & 28 \\ +PS-1 & & \\ + I/O (cpu-sec) & 960 & 557 \\ + CPU (cpu-sec) & 2600 & 2600 \\ + \# cpus & 30 & 26 \\ +PS-4 & & \\ + I/O (cpu-sec) & 480 & 278 \\ + CPU (cpu-sec) & 1300 & 1300 \\ + \# cpus & 59 & 53 \\ +\hline +\end{tabular} +\end{center} +\end{table} + +\subsubsection{Conclusions} + +Table~\ref{throughput} presents one way of analysing the hardware +requirements, making a specific set of assumptions about the number of +nodes for the two phases and the expected network and disk +bandwidths. The important conclusion in this analysis is the implied +number of GHz per processor, given the assumptions laid out. +Phase 2 is specified to have 240 OTA nodes, while Phase 4 is specified +to have roughly 60 static sky nodes. The range of Phase 2 CPU +requirements implies that each CPU needs to have speeds in the range +of 2.0 - 3.6 GHz, which sound very plausible for the year 2007, since +these apply to PS-4. + +Another way to represent this information is to use the total number +of MB I/O and the total number of GHz-sec required for the two stages, +confront these with an assumption for the bandwidth per network +adapter and an assumption for the CPU speed and use those numbers to +calculate the minimum number of nodes (CPUs) needed to sustain the +timing requirements. There are quite a few parameters and options to +choose from. We have assumed that for PS-1, the time between major +frames (4 images combined in Phase 4) is 120 seconds, and 30 seconds +for PS-4. We have also assumed that each CPU has one network adapter +associated with it, and use the numbers of 50 MB/sec for PS-1 era +network adapters and 100 MB/sec for the PS-4 network adapters (since +there has been some steady improvement in GigE hardware over the past +year). We have also assumed each PS-1 CPU is rated at 3 GHz and those +for PS-4 are rated at 6 GHz (somewhat conservative since 3 GHz +machines are already available). Tables~\ref{NP2} and \ref{NP4} show +the load and resulting number of nodes for both Phase 2 and Phase 4 +for both the PS-1 and PS-4 assumptions, using the I/O numbers for all +of the scenarios above. Note that in these discussions, we make the +idealized assumption that the computational and I/O portions of each +process are completely serial. As a result, the CPU is completely +used to perform the I/O during the I/O phase, avoiding any concern +about I/O load on the processor during analysis. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\section{Notes} + +\subsection{Cell vs OTA vs Mosaic vs Major Frame} + +There are several levels of input data pixel groups: Cell, OTA, +Mosaic, and Major Frame. It is necessary to make the association +between the data of one level and that of the next in a way that is +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 +missing from a mosaic camera, that information is also known and must +be carried though the meta-data. A more difficult association is that +between the telescopes to define the major frame. Some possibilities: + +\begin{enumerate} +\item exposures in a major frame are always synchronized; the +telescopes are required to take exposures in a coordinated fashion and +these linked exposures are identified as being part of a specific +major frame by the TCS or PTS. +\item exposures may be taken in a coordinated fashion, and identified +by the TCS or PTS as part of a specific major frame, but not all +exposures are required to be taken in this fashion. Independent +images are handled by the IPP differently (Phase 3 and Phase 4 are not +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 +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 +not be the entity which defines these major-frame associations; this +may be the role of some component in the IPP. Different types of +major frames may be defined depending on the correlation period in +time or space. For example, a major frame in which the telescopes are +pointing at the same position in the sky to within a few pixels and +with exposures taken within a second can be treated with more special +assumptions (minimal differential distortion; moving objects +coincident) than a major frame in which the offsets are larger in +either dimension. +\end{enumerate} + +A decisions between these possibilities will drive some requirements +either on the IPP side or on the PTS/TCS side. + +\subsection{Identifying ghosts, spikes, etc} + +One of the functions currenly defined for Phase 1 is the prediction of +the location of the bright star spikes, ghost images, and regions of +complex astronomical background. Elsewhere in the IPP, these +identifications are used to excise or mark image pixels. How these +regions are defined and saved are is not very clear. I propose that +we use the mask image to mark as bit-flags all of these cosmetic pixel +flagging issues. If we need to save this information, for the short +period that the input science images are kept, then it is only a small +addition of data. + +\subsection{Delete Phase 1?} + +except for the moving objects, phase 1 jobs are very light: include as +part of phase 2 steps? How long will the moving object ephemeris +likely take? The output of this analysis will not be required until +Phase 4. + +\subsection{Pending Sky-cell / OTA table} + +Define a pending sky-cell / OTA table to define the overlaps and to +give something which the scheduler can query to decide when to +initiate phase 4. + +\section{Appendices} + + +\bibliographystyle{plain} +\bibliography{panstarrs} +\end{document} + +%%%%%% Phase 0 has been dropped: identifying the moving objects is not needed + +\paragraph{Phase 0 : night preparation} + +Phase 0 is the night preparation phase of the IPP analysis system. +There may be potentially many pieces of information which apply to the +processing for an entire night and which take substantial time to +calculate. these are pre-calculated by the phase 0 stage and stored +in a database table for reference by other stages of the processing +system. Currently, the only quantity calculated by Phase 0 is the +collection of known moving object ephemerids. + +At various stages in the IPP analysis, it is necessary to know the +location of known moving objects (main belt asteroids, comets, +Kuiper-belt objects, any other classes of asteroids) in relation to +specific images obtained. If moving object orbits were trivial to +calculate, or if the number was limited, this would be a simple +problem of three dimensional intersections. However, complete orbits +are not trivial and there may be tens of thousands to millions of +possible objects of interest. To simplify the task, it is possible to +reduce the parameter space of the search by pre-calculating the orbit +segments of all objects for a given night and saving fiducial points +of the orbit in a database table. Later systems which require the +position of objects in a specific image can use linear interpolation +between these fiducial points to identify the likely objects, and +potentially additional non-linear orbital calculations to refine the +positions. + +The database table of object fiducial positions must include the +following information: + +\begin{itemize} +\item object ID +\item epoch +\item RA at epoch +\item DEC at epoch +\item dRA at epoch +\item dDEC at epoch +\item R magnitude? +\item date of calculation? +\item lifetime? +\end{itemize} + +The input for this calculation is the table of known moving objects +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 +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 +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 +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?} + + + +%%% phase 2 metadata +\milsection{Metadata} + +The following metadata associated with the images are required for +Phase~2 operation: +\begin{itemize} +\item The orthogonal transfer (OT) image shifts made during the +exposure --- in order to create a convolution kernel; +\item Time of observation --- for selecting the appropriate detrend +images; +\item Filter --- for selecting the appropriate detrend images; +\item Telescope identification --- for selecting the appropriate +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 read noise --- for calculating photometric errors and +determining the quality of the overscan; +\end{itemize} + +\milsection{Pixel Masks} +\label{ap:masks} + +This section describes the requirements on Bad Pixel Masks (BPMs). +These will consist in of bit masks for each pixel. For Phase 2, flags +are required for at least each of the following pixel attributes: +\begin{enumerate} +\item The pixel is a charge trap; +\item The pixel is a bad column; +\item The pixel is saturated in the A/D converter; +\item The pixel is non-positive in the flat-field; +\item The pixel is part of a row that has excess noise; and +\item The pixel is determined to be a cosmic ray, based on its +morphology. +\end{enumerate} + +Of these, only masks for the charge traps need to be grown by the +extent of the OT convolution kernel. For other pixel types, +orthogonal transfer of the flux in this pixel will not (necessarily) +affect the flux in neighbouring pixels + +\milsection{Object Catalogues} +\label{ap:catalogues} + +Object catalogues from Phase 2 shall consist of at least the +following elements for each object: +\begin{enumerate} +\item Object centre, with corresponding errors; +\item Object magnitude, with corresponding error; +\item Object isophotal magnitude, with corresponding error; +\item Object FWHM; +\item Object elliptical axis lengths; and +\item Object position angle for ellipse. +\end{enumerate} + +Though further details may be required for catalogues in Phase~4, +the above details are minimum requirements for Phase~2 catalogues. + Index: /trunk/doc/design/pics/overview.eps~ =================================================================== --- /trunk/doc/design/pics/overview.eps~ (revision 409) +++ /trunk/doc/design/pics/overview.eps~ (revision 409) @@ -0,0 +1,1403 @@ +%!PS-Adobe-2.0 EPSF-1.2 +%%Title: dataflow.sxd +%%Creator: OpenOffice.org 1.0.2 +%%CreationDate: Thu Mar 4 15:19:44 2004 +%%For: eugene +%%Pages: 1 +%%DocumentFonts: LuxiSansHSet1 +%%BoundingBox: 44 422 467 785 +%%Page: 1 1 +%%BeginDocument: /tmp/eps.UmOfvP +/ISO1252Encoding [ +/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef +/space /exclam /quotedbl /numbersign /dollar /percent /ampersand /quotesingle +/parenleft /parenright /asterisk /plus /comma /hyphen /period /slash +/zero /one /two /three /four /five /six /seven +/eight /nine /colon /semicolon /less /equal /greater /question +/at /A /B /C /D /E /F /G +/H /I /J /K /L /M /N /O +/P /Q /R /S /T /U /V /W +/X /Y /Z /bracketleft /backslash /bracketright /asciicircum /underscore +/grave /a /b /c /d /e /f /g +/h /i /j /k /l /m /n /o +/p /q /r /s /t /u /v /w +/x /y /z /braceleft /bar /braceright /asciitilde /unused +/Euro /unused /quotesinglbase /florin /quotedblbase /ellipsis /dagger /daggerdbl +/circumflex /perthousand /Scaron /guilsinglleft /OE /unused /Zcaron /unused +/unused /quoteleft /quoteright /quotedblleft /quotedblright /bullet /endash /emdash +/tilde /trademark /scaron /guilsinglright /oe /unused /zcaron /Ydieresis +/space /exclamdown /cent /sterling /currency /yen /brokenbar /section +/dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen /registered /macron +/degree /plusminus /twosuperior /threesuperior /acute /mu /paragraph /periodcentered +/cedilla /onesuperior /ordmasculine /guillemotright /onequarter /onehalf /threequarters /questiondown +/Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring /AE /Ccedilla +/Egrave /Eacute /Ecircumflex /Edieresis /Igrave /Iacute /Icircumflex /Idieresis +/Eth /Ntilde /Ograve /Oacute /Ocircumflex /Otilde /Odieresis /multiply +/Oslash /Ugrave /Uacute /Ucircumflex /Udieresis /Yacute /Thorn /germandbls +/agrave /aacute /acircumflex /atilde /adieresis /aring /ae /ccedilla +/egrave /eacute /ecircumflex /edieresis /igrave /iacute /icircumflex /idieresis +/eth /ntilde /ograve /oacute /ocircumflex /otilde /odieresis /divide +/oslash /ugrave /uacute /ucircumflex /udieresis /yacute /thorn /ydieresis] def + +/psp_definefont { exch dup findfont dup length dict begin { 1 index /FID ne +{ def } { pop pop } ifelse } forall /Encoding 3 -1 roll def +currentdict end exch pop definefont pop } def + +/pathdict dup 8 dict def load begin +/rcmd { { currentfile 1 string readstring pop 0 get dup 32 gt { exit } +{ pop } ifelse } loop dup 126 eq { pop exit } if 65 sub dup 16#3 and 1 +add exch dup 16#C and -2 bitshift 16#3 and 1 add exch 16#10 and 16#10 +eq 3 1 roll exch } def +/rhex { dup 1 sub exch currentfile exch string readhexstring pop dup 0 +get dup 16#80 and 16#80 eq dup 3 1 roll { 16#7f and } if 2 index 0 3 +-1 roll put 3 1 roll 0 0 1 5 -1 roll { 2 index exch get add 256 mul } +for 256 div exch pop exch { neg } if } def +/xcmd { rcmd exch rhex exch rhex exch 5 -1 roll add exch 4 -1 roll add +1 index 1 index 5 -1 roll { moveto } { lineto } ifelse } def end +/readpath { 0 0 pathdict begin { xcmd } loop end pop pop } def + +systemdict /languagelevel known not { +/xshow { exch dup length 0 1 3 -1 roll 1 sub { dup 3 index exch get +exch 2 index exch get 1 string dup 0 4 -1 roll put currentpoint 3 -1 +roll show moveto 0 rmoveto } for pop pop } def +/rectangle { 4 -2 roll moveto 1 index 0 rlineto 0 exch rlineto neg 0 +rlineto closepath } def +/rectfill { rectangle fill } def +/rectstroke { rectangle stroke } def } if + +/psp_lzwfilter { currentfile /ASCII85Decode filter /LZWDecode filter } def +/psp_ascii85filter { currentfile /ASCII85Decode filter } def +/psp_lzwstring { psp_lzwfilter 1024 string readstring } def +/psp_ascii85string { psp_ascii85filter 1024 string readstring } def +/psp_imagedict { +/psp_bitspercomponent { 3 eq { 1 }{ 8 } ifelse } def +/psp_decodearray { [ [0 1 0 1 0 1] [0 255] [0 1] [0 255] ] exch get } +def 7 dict dup +/ImageType 1 put dup +/Width 7 -1 roll put dup +/Height 5 index put dup +/BitsPerComponent 4 index psp_bitspercomponent put dup +/Decode 5 -1 roll psp_decodearray put dup +/ImageMatrix [1 0 0 1 0 0] dup 5 8 -1 roll put put dup +/DataSource 4 -1 roll 1 eq { psp_lzwfilter } { psp_ascii85filter } ifelse put +} def +% +<> setpagedevice +% +gsave +[0.24 0 0 -0.24 18 824] concat +gsave +% Original font name: LuxiSans +30 dict begin +/PaintType 0 def +/FontType 3 def +/StrokeWidth 0 def +/FontName /LuxiSansHSet1 def +/XUID [103 0 0 16#76C7BB62 39 16#530C6258 16#E084E573] def +/FontMatrix [.001 0 0 .001 0 0] def +/FontBBox [-215 -210 988 992] def +/Encoding 256 array def + 0 1 255 {Encoding exch /.notdef put} for + Encoding 32 /glyph0 put + Encoding 38 /glyph1 put + Encoding 47 /glyph2 put + Encoding 65 /glyph3 put + Encoding 66 /glyph4 put + Encoding 67 /glyph5 put + Encoding 68 /glyph6 put + Encoding 69 /glyph7 put + Encoding 73 /glyph8 put + Encoding 74 /glyph9 put + Encoding 76 /glyph10 put + Encoding 77 /glyph11 put + Encoding 79 /glyph12 put + Encoding 80 /glyph13 put + Encoding 83 /glyph14 put + Encoding 84 /glyph15 put + Encoding 97 /glyph16 put + Encoding 98 /glyph17 put + Encoding 99 /glyph18 put + Encoding 100 /glyph19 put + Encoding 101 /glyph20 put + Encoding 103 /glyph21 put + Encoding 104 /glyph22 put + Encoding 105 /glyph23 put + Encoding 106 /glyph24 put + Encoding 107 /glyph25 put + Encoding 108 /glyph26 put + Encoding 109 /glyph27 put + Encoding 110 /glyph28 put + Encoding 111 /glyph29 put + Encoding 112 /glyph30 put + Encoding 114 /glyph31 put + Encoding 115 /glyph32 put + Encoding 116 /glyph33 put + Encoding 117 /glyph34 put + Encoding 118 /glyph35 put + Encoding 119 /glyph36 put + Encoding 120 /glyph37 put + Encoding 121 /glyph38 put +/CharProcs 40 dict def + CharProcs begin + /.notdef {} def + /glyph0 { + 277 0 0 0 0 0 setcachedevice + } bind def + /glyph1 { + 666 0 27 -18 631 740 setcachedevice + 500 0 moveto + 464 42 lineto + 399 2 337 -18 278 -18 curveto + 207 -18 147 3 99 48 curveto + 51 92 27 148 27 215 curveto + 27 282 48 336 90 377 curveto + 115 401 150 423 197 441 curveto + 169 494 154 540 154 579 curveto + 154 628 169 667 199 696 curveto + 229 726 270 740 321 740 curveto + 370 740 408 728 437 701 curveto + 465 675 479 639 479 595 curveto + 479 546 460 503 422 468 curveto + 399 447 366 426 322 406 curveto + 377 307 431 225 485 160 curveto + 518 201 534 263 534 345 curveto + 534 384 lineto + 629 384 lineto + 629 271 596 179 530 107 curveto + 559 71 592 35 631 0 curveto + 500 0 lineto + closepath + 422 98 moveto + 358 171 295 267 231 385 curveto + 200 370 176 353 159 333 curveto + 136 307 124 273 124 232 curveto + 124 183 140 141 173 106 curveto + 207 71 247 54 293 54 curveto + 330 54 373 68 422 98 curveto + closepath + 286 466 moveto + 317 480 340 495 355 510 curveto + 377 533 389 561 389 593 curveto + 389 643 366 668 320 668 curveto + 272 668 248 642 248 589 curveto + 248 557 259 519 282 474 curveto + 286 466 lineto + closepath + fill + } bind def + /glyph2 { + 277 0 -28 -144 307 722 setcachedevice + -28 -144 moveto + 231 722 lineto + 307 722 lineto + 46 -144 lineto + -28 -144 lineto + closepath + fill + } bind def + /glyph3 { + 666 0 9 0 655 722 setcachedevice + 9 0 moveto + 283 722 lineto + 385 722 lineto + 655 0 lineto + 544 0 lineto + 469 200 lineto + 179 200 lineto + 104 0 lineto + 9 0 lineto + closepath + 208 276 moveto + 441 276 lineto + 325 585 lineto + 208 276 lineto + closepath + fill + } bind def + /glyph4 { + 666 0 80 0 601 722 setcachedevice + 80 0 moveto + 80 722 lineto + 312 722 lineto + 407 722 474 710 513 686 curveto + 552 661 572 620 572 561 curveto + 572 507 553 463 514 429 curveto + 491 409 457 392 412 376 curveto + 468 359 511 339 540 314 curveto + 580 280 601 235 601 180 curveto + 601 129 584 86 551 52 curveto + 528 28 497 13 458 7 curveto + 429 2 388 0 337 0 curveto + 80 0 lineto + closepath + 183 76 moveto + 258 76 lineto + 354 76 417 83 447 98 curveto + 477 112 492 141 492 187 curveto + 492 236 473 274 434 300 curveto + 395 327 340 340 266 340 curveto + 183 340 lineto + 183 76 lineto + closepath + 183 405 moveto + 270 405 lineto + 401 405 466 451 466 543 curveto + 466 589 448 619 410 631 curveto + 382 641 337 645 277 645 curveto + 183 645 lineto + 183 405 lineto + closepath + fill + } bind def + /glyph5 { + 722 0 56 -18 660 740 setcachedevice + 660 37 moveto + 585 0 506 -18 420 -18 curveto + 302 -18 211 14 149 78 curveto + 87 143 56 236 56 360 curveto + 56 483 88 577 151 643 curveto + 214 708 305 740 425 740 curveto + 492 740 569 730 659 708 curveto + 659 612 lineto + 558 646 478 664 419 664 curveto + 338 664 275 638 231 585 curveto + 188 534 166 459 166 361 curveto + 166 266 189 192 236 140 curveto + 282 88 348 62 432 62 curveto + 503 62 579 83 660 125 curveto + 660 37 lineto + closepath + fill + } bind def + /glyph6 { + 722 0 80 0 676 722 setcachedevice + 80 0 moveto + 80 722 lineto + 312 722 lineto + 555 722 676 607 676 377 curveto + 676 258 645 165 581 99 curveto + 518 33 429 0 313 0 curveto + 80 0 lineto + closepath + 183 76 moveto + 306 76 lineto + 479 76 566 173 566 366 curveto + 566 479 532 560 463 606 curveto + 443 620 419 629 392 635 curveto + 358 642 314 645 258 645 curveto + 183 645 lineto + 183 76 lineto + closepath + fill + } bind def + /glyph7 { + 666 0 93 0 638 722 setcachedevice + 93 0 moveto + 93 722 lineto + 617 722 lineto + 617 645 lineto + 195 645 lineto + 195 414 lineto + 568 414 lineto + 568 338 lineto + 195 338 lineto + 195 76 lineto + 638 76 lineto + 638 0 lineto + 93 0 lineto + closepath + fill + } bind def + /glyph8 { + 277 0 87 0 190 722 setcachedevice + 87 0 moveto + 87 722 lineto + 190 722 lineto + 190 0 lineto + 87 0 lineto + closepath + fill + } bind def + /glyph9 { + 500 0 23 -144 410 722 setcachedevice + 23 -113 moveto + 23 -24 lineto + 79 -49 131 -62 180 -62 curveto + 235 -62 271 -49 287 -23 curveto + 300 -1 307 35 307 87 curveto + 307 722 lineto + 410 722 lineto + 410 91 lineto + 410 -65 332 -144 175 -144 curveto + 123 -144 72 -134 23 -113 curveto + closepath + fill + } bind def + /glyph10 { + 556 0 80 0 537 722 setcachedevice + 80 0 moveto + 80 722 lineto + 183 722 lineto + 183 76 lineto + 537 76 lineto + 537 0 lineto + 80 0 lineto + closepath + fill + } bind def + /glyph11 { + 833 0 80 0 752 722 setcachedevice + 80 0 moveto + 80 722 lineto + 222 722 lineto + 421 163 lineto + 625 722 lineto + 752 722 lineto + 752 0 lineto + 656 0 lineto + 656 587 lineto + 459 48 lineto + 360 48 lineto + 168 589 lineto + 168 0 lineto + 80 0 lineto + closepath + fill + } bind def + /glyph12 { + 777 0 45 -18 732 740 setcachedevice + 389 740 moveto + 493 740 576 706 639 637 curveto + 701 568 732 477 732 362 curveto + 732 245 702 153 639 84 curveto + 576 16 491 -18 384 -18 curveto + 292 -18 217 10 157 66 curveto + 83 137 45 235 45 361 curveto + 45 477 76 568 139 637 curveto + 201 706 285 740 389 740 curveto + closepath + 389 664 moveto + 315 664 258 637 216 584 curveto + 176 531 155 457 155 361 curveto + 155 267 175 193 216 139 curveto + 257 85 313 58 386 58 curveto + 454 58 507 80 547 123 curveto + 598 176 623 255 623 362 curveto + 623 457 602 531 561 584 curveto + 520 637 462 664 389 664 curveto + closepath + fill + } bind def + /glyph13 { + 666 0 81 0 643 722 setcachedevice + 81 0 moveto + 81 722 lineto + 364 722 lineto + 439 722 492 718 524 709 curveto + 557 701 584 684 604 659 curveto + 630 628 643 585 643 531 curveto + 643 369 541 287 334 287 curveto + 184 287 lineto + 184 0 lineto + 81 0 lineto + closepath + 184 364 moveto + 330 364 lineto + 466 364 535 418 535 525 curveto + 535 577 517 611 481 626 curveto + 452 639 402 645 332 645 curveto + 184 645 lineto + 184 364 lineto + closepath + fill + } bind def + /glyph14 { + 666 0 58 -18 606 740 setcachedevice + 58 25 moveto + 58 126 lineto + 154 81 250 58 343 58 curveto + 448 58 501 97 501 175 curveto + 501 215 487 245 458 264 curveto + 436 279 399 294 349 311 curveto + 251 343 lineto + 125 384 62 452 62 547 curveto + 62 676 150 740 327 740 curveto + 402 740 480 730 562 709 curveto + 562 615 lineto + 477 647 397 664 320 664 curveto + 214 664 161 628 161 555 curveto + 161 527 171 504 191 487 curveto + 211 469 248 452 299 435 curveto + 400 402 lineto + 476 377 529 349 560 317 curveto + 591 286 606 243 606 190 curveto + 606 126 583 75 535 38 curveto + 488 0 423 -18 339 -18 curveto + 258 -18 164 -3 58 25 curveto + closepath + fill + } bind def + /glyph15 { + 610 0 9 0 600 722 setcachedevice + 253 0 moveto + 253 645 lineto + 9 645 lineto + 9 722 lineto + 600 722 lineto + 600 645 lineto + 356 645 lineto + 356 0 lineto + 253 0 lineto + closepath + fill + } bind def + /glyph16 { + 556 0 46 -12 536 541 setcachedevice + 377 67 moveto + 317 14 259 -12 202 -12 curveto + 156 -12 119 1 89 28 curveto + 61 55 46 90 46 133 curveto + 46 253 144 313 341 313 curveto + 363 313 lineto + 363 377 lineto + 363 438 330 469 261 469 curveto + 209 469 152 454 92 422 curveto + 92 502 lineto + 159 528 221 541 280 541 curveto + 342 541 388 529 416 502 curveto + 445 476 459 435 459 377 curveto + 459 137 lineto + 459 82 477 54 510 54 curveto + 515 54 521 55 529 56 curveto + 536 3 lineto + 512 -6 488 -12 464 -12 curveto + 442 -12 424 -5 410 6 curveto + 396 18 385 38 377 67 curveto + closepath + 363 119 moveto + 363 256 lineto + 332 257 lineto + 312 258 291 257 267 253 curveto + 186 242 145 207 145 147 curveto + 145 93 175 66 234 66 curveto + 275 66 318 83 363 119 curveto + closepath + fill + } bind def + /glyph17 { + 556 0 75 -12 513 770 setcachedevice + 171 343 moveto + 171 72 lineto + 215 64 249 60 271 60 curveto + 363 60 409 129 409 269 curveto + 409 328 400 374 382 407 curveto + 364 441 340 458 309 458 curveto + 269 458 222 419 171 343 curveto + closepath + 171 430 moveto + 189 463 208 488 229 505 curveto + 257 529 291 541 330 541 curveto + 385 541 429 518 462 470 curveto + 496 422 513 358 513 279 curveto + 513 187 492 115 448 63 curveto + 405 13 343 -12 263 -12 curveto + 234 -12 203 -8 171 0 curveto + 75 -5 lineto + 75 770 lineto + 171 770 lineto + 171 430 lineto + closepath + fill + } bind def + /glyph18 { + 500 0 41 -12 452 541 setcachedevice + 452 16 moveto + 393 -2 337 -12 285 -12 curveto + 212 -12 153 13 108 64 curveto + 64 116 41 182 41 265 curveto + 41 351 64 419 110 468 curveto + 155 517 219 541 300 541 curveto + 341 541 390 536 446 524 curveto + 446 444 lineto + 393 460 350 468 318 468 curveto + 206 468 150 400 150 265 curveto + 150 201 165 152 193 117 curveto + 222 83 262 65 314 65 curveto + 354 65 399 76 452 99 curveto + 452 16 lineto + closepath + fill + } bind def + /glyph19 { + 556 0 41 -12 480 770 setcachedevice + 384 186 moveto + 384 457 lineto + 339 465 306 469 284 469 curveto + 192 469 145 399 145 259 curveto + 145 202 155 156 173 122 curveto + 191 89 215 72 246 72 curveto + 287 72 333 110 384 186 curveto + closepath + 384 99 moveto + 366 66 347 41 326 23 curveto + 298 0 264 -12 225 -12 curveto + 170 -12 126 11 92 60 curveto + 59 107 41 171 41 250 curveto + 41 343 63 415 107 465 curveto + 150 516 212 541 291 541 curveto + 322 541 353 538 384 530 curveto + 384 770 lineto + 480 770 lineto + 480 0 lineto + 384 0 lineto + 384 99 lineto + closepath + fill + } bind def + /glyph20 { + 556 0 41 -12 499 541 setcachedevice + 399 322 moveto + 398 354 395 378 389 395 curveto + 373 445 336 470 279 470 curveto + 240 470 208 458 186 435 curveto + 164 413 150 375 144 322 curveto + 399 322 lineto + closepath + 494 93 moveto + 494 17 lineto + 428 -1 368 -12 312 -12 curveto + 230 -12 164 13 115 64 curveto + 66 116 41 185 41 271 curveto + 41 354 63 419 106 468 curveto + 149 517 208 541 281 541 curveto + 366 541 425 512 460 452 curveto + 486 407 499 350 497 279 curveto + 497 250 lineto + 143 250 lineto + 146 211 153 182 162 161 curveto + 190 94 248 61 333 61 curveto + 381 61 435 71 494 93 curveto + closepath + fill + } bind def + /glyph21 { + 556 0 45 -205 483 541 setcachedevice + 387 210 moveto + 387 457 lineto + 342 465 309 469 288 469 curveto + 196 469 149 406 149 280 curveto + 149 224 158 179 176 145 curveto + 194 113 219 96 249 96 curveto + 290 96 336 134 387 210 curveto + closepath + 387 123 moveto + 370 90 351 65 330 48 curveto + 301 24 268 12 229 12 curveto + 175 12 130 36 96 83 curveto + 62 130 45 192 45 269 curveto + 45 355 67 422 110 470 curveto + 154 518 215 541 294 541 curveto + 325 541 355 538 387 530 curveto + 483 530 lineto + 483 144 lineto + 483 61 479 0 470 -40 curveto + 447 -149 365 -205 226 -205 curveto + 167 -205 108 -195 48 -176 curveto + 48 -92 lineto + 118 -118 177 -132 225 -132 curveto + 333 -132 387 -74 387 40 curveto + 387 123 lineto + closepath + fill + } bind def + /glyph22 { + 556 0 75 0 486 770 setcachedevice + 75 0 moveto + 75 770 lineto + 171 770 lineto + 171 430 lineto + 195 463 218 488 241 505 curveto + 275 529 312 541 352 541 curveto + 441 541 486 488 486 380 curveto + 486 0 lineto + 390 0 lineto + 390 349 lineto + 390 392 386 421 376 436 curveto + 368 451 351 459 326 459 curveto + 273 459 222 420 171 343 curveto + 171 0 lineto + 75 0 lineto + closepath + fill + } bind def + /glyph23 { + 222 0 62 0 159 722 setcachedevice + 62 0 moveto + 62 530 lineto + 159 530 lineto + 159 0 lineto + 62 0 lineto + closepath + 62 626 moveto + 62 722 lineto + 159 722 lineto + 159 626 lineto + 62 626 lineto + closepath + fill + } bind def + /glyph24 { + 222 0 -75 -204 161 722 setcachedevice + -75 -188 moveto + -75 -112 lineto + -49 -125 -25 -132 -2 -132 curveto + 29 -132 48 -120 56 -96 curveto + 62 -76 64 -44 64 0 curveto + 64 530 lineto + 161 530 lineto + 161 0 lineto + 161 -136 109 -204 5 -204 curveto + -22 -204 -49 -199 -75 -188 curveto + closepath + 64 626 moveto + 64 722 lineto + 161 722 lineto + 161 626 lineto + 64 626 lineto + closepath + fill + } bind def + /glyph25 { + 500 0 75 0 491 770 setcachedevice + 75 0 moveto + 75 770 lineto + 171 770 lineto + 171 272 lineto + 349 530 lineto + 440 530 lineto + 271 279 lineto + 491 0 lineto + 374 0 lineto + 171 271 lineto + 171 0 lineto + 75 0 lineto + closepath + fill + } bind def + /glyph26 { + 222 0 62 0 159 770 setcachedevice + 62 0 moveto + 62 770 lineto + 159 770 lineto + 159 0 lineto + 62 0 lineto + closepath + fill + } bind def + /glyph27 { + 833 0 75 0 763 541 setcachedevice + 75 0 moveto + 75 530 lineto + 171 530 lineto + 171 430 lineto + 199 473 223 501 241 516 curveto + 262 533 290 541 324 541 curveto + 367 541 401 528 427 500 curveto + 442 485 456 461 467 430 curveto + 496 473 519 502 537 516 curveto + 558 533 586 541 621 541 curveto + 716 541 763 490 763 385 curveto + 763 0 lineto + 667 0 lineto + 666 370 lineto + 666 431 644 461 596 461 curveto + 555 461 512 426 467 355 curveto + 467 0 lineto + 371 0 lineto + 371 370 lineto + 371 431 347 461 300 461 curveto + 258 461 215 426 171 355 curveto + 171 0 lineto + 75 0 lineto + closepath + fill + } bind def + /glyph28 { + 556 0 75 0 486 541 setcachedevice + 75 0 moveto + 75 530 lineto + 171 530 lineto + 171 430 lineto + 195 463 218 488 241 505 curveto + 275 529 312 541 352 541 curveto + 441 541 486 488 486 380 curveto + 486 0 lineto + 390 0 lineto + 390 349 lineto + 390 392 386 421 376 436 curveto + 368 451 351 459 326 459 curveto + 273 459 222 420 171 343 curveto + 171 0 lineto + 75 0 lineto + closepath + fill + } bind def + /glyph29 { + 556 0 41 -12 513 541 setcachedevice + 277 541 moveto + 350 541 407 517 450 467 curveto + 492 418 513 351 513 265 curveto + 513 179 492 110 450 61 curveto + 408 12 349 -12 274 -12 curveto + 210 -12 158 8 118 48 curveto + 67 100 41 171 41 265 curveto + 41 350 62 418 105 467 curveto + 147 517 205 541 277 541 curveto + closepath + 277 469 moveto + 190 469 145 401 145 265 curveto + 145 128 189 60 277 60 curveto + 365 60 409 128 409 267 curveto + 409 402 366 469 277 469 curveto + closepath + fill + } bind def + /glyph30 { + 556 0 75 -192 513 541 setcachedevice + 171 -192 moveto + 75 -192 lineto + 75 530 lineto + 171 530 lineto + 171 430 lineto + 189 463 208 488 229 505 curveto + 257 529 291 541 330 541 curveto + 385 541 429 518 462 470 curveto + 496 422 513 358 513 279 curveto + 513 187 492 115 448 63 curveto + 405 13 343 -12 263 -12 curveto + 234 -12 203 -8 171 0 curveto + 171 -192 lineto + closepath + 171 343 moveto + 171 72 lineto + 215 64 249 60 271 60 curveto + 363 60 409 129 409 269 curveto + 409 328 400 374 382 407 curveto + 364 441 340 458 309 458 curveto + 269 458 222 419 171 343 curveto + closepath + fill + } bind def + /glyph31 { + 333 0 75 0 326 541 setcachedevice + 75 0 moveto + 75 530 lineto + 171 530 lineto + 171 430 lineto + 185 464 200 489 216 505 curveto + 239 529 267 541 298 541 curveto + 305 541 313 541 326 539 curveto + 326 449 lineto + 309 455 295 458 285 458 curveto + 250 458 211 422 171 349 curveto + 171 0 lineto + 75 0 lineto + closepath + fill + } bind def + /glyph32 { + 500 0 56 -12 443 541 setcachedevice + 56 18 moveto + 56 106 lineto + 121 76 181 60 235 60 curveto + 309 60 346 85 346 138 curveto + 346 173 321 200 269 217 curveto + 183 245 lineto + 101 272 59 322 59 394 curveto + 59 492 126 541 261 541 curveto + 300 541 347 537 402 526 curveto + 402 445 lineto + 354 461 304 469 255 469 curveto + 188 469 154 448 154 403 curveto + 154 372 177 348 223 333 curveto + 300 308 lineto + 395 277 443 224 443 147 curveto + 443 98 424 59 386 30 curveto + 349 2 297 -12 231 -12 curveto + 180 -12 122 -1 56 18 curveto + closepath + fill + } bind def + /glyph33 { + 277 0 14 -12 272 635 setcachedevice + 258 -2 moveto + 239 -8 221 -12 203 -12 curveto + 117 -12 74 40 74 146 curveto + 74 458 lineto + 14 458 lineto + 14 530 lineto + 74 530 lineto + 74 626 lineto + 170 635 lineto + 170 530 lineto + 272 530 lineto + 272 458 lineto + 170 458 lineto + 170 164 lineto + 170 122 173 94 181 80 curveto + 188 67 203 60 226 60 curveto + 238 60 249 62 258 65 curveto + 258 -2 lineto + closepath + fill + } bind def + /glyph34 { + 556 0 69 -12 480 530 setcachedevice + 384 0 moveto + 384 99 lineto + 360 66 337 41 314 24 curveto + 281 0 244 -12 204 -12 curveto + 114 -12 69 41 69 149 curveto + 69 530 lineto + 165 530 lineto + 165 180 lineto + 165 138 169 109 178 93 curveto + 187 78 204 70 229 70 curveto + 282 70 333 109 384 186 curveto + 384 530 lineto + 480 530 lineto + 480 0 lineto + 384 0 lineto + closepath + fill + } bind def + /glyph35 { + 500 0 9 0 494 530 setcachedevice + 197 0 moveto + 9 530 lineto + 106 530 lineto + 253 117 lineto + 408 530 lineto + 494 530 lineto + 293 0 lineto + 197 0 lineto + closepath + fill + } bind def + /glyph36 { + 722 0 5 0 715 530 setcachedevice + 133 0 moveto + 5 530 lineto + 99 530 lineto + 195 130 lineto + 317 530 lineto + 413 530 lineto + 520 129 lineto + 632 530 lineto + 715 530 lineto + 566 0 lineto + 469 0 lineto + 357 410 lineto + 230 0 lineto + 133 0 lineto + closepath + fill + } bind def + /glyph37 { + 500 0 13 0 484 530 setcachedevice + 13 0 moveto + 186 280 lineto + 19 530 lineto + 130 530 lineto + 263 331 lineto + 382 530 lineto + 471 530 lineto + 309 263 lineto + 484 0 lineto + 374 0 lineto + 230 212 lineto + 102 0 lineto + 13 0 lineto + closepath + fill + } bind def + /glyph38 { + 500 0 9 -192 494 530 setcachedevice + 197 0 moveto + 9 530 lineto + 106 530 lineto + 250 123 lineto + 409 530 lineto + 494 530 lineto + 213 -192 lineto + 113 -192 lineto + 197 0 lineto + closepath + fill + } bind def + end +/BuildGlyph { + exch /CharProcs get exch + 2 copy known not + {pop /.notdef} if + get exec +} bind def +/BuildChar { + 1 index /Encoding get exch get + 1 index /BuildGlyph get exec +} bind def +currentdict end +/LuxiSansHSet1 exch definefont pop +readpath +V00C202EDE014D00B0000A6E814D00B0080A6~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +1 setlinewidth +readpath +V01680393E80A600B0080A6E014D00B0000A6E80A700~ +stroke +241 849 moveto +/LuxiSansHSet1 findfont 47 -47 matrix scale makefont setfont +<506978656C536572766572> +[31 10 24 26 10 31 27 16 23 25 0] +xshow +readpath +V05B50184E016200A006FE816200A00EF~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V066601F3E80B100A00EFE016200A006FE80B100~ +stroke +1508 460 moveto +<4D657461646174614442> +[38 27 13 26 26 26 13 26 34 0] +xshow +readpath +V037703E6E00DE00B0000A7E80DE00B0080A7~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V03E6048DAEF00B0080A7E00DE00B0000A7AEF00~ +stroke +929 1098 moveto +<4F626A4442> +[36 26 10 34 0] +xshow +readpath +V03E602B5E811500A8F82A8D85A8B89A898BA868EA828EA0000A028FA068DA098CA0B88A0D86A0F8 +2E022A00A0F02A0D06A0C08A080CA060DA020FA0000A820EA860EA880BA8C09A8D05A8F02E811500~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V03E602B5E811500A8F82A8D85A8B89A898BA868EA828EA028FA068DA098CA0B88A0D86A0F82E022 +A00A0F02A0D06A0C08A080CA060DA020FA820EA860EA880BA8C09A8D05A8F02E811500~ +stroke +688 655 moveto +<436F6E74726F6C6C6572> +[34 25 26 14 16 26 10 10 27 0] +xshow +222 243 moveto +299 166 lineto +stroke +234 311 moveto +378 166 lineto +stroke +290 333 moveto +455 168 lineto +stroke +369 333 moveto +496 206 lineto +stroke +449 332 moveto +498 283 lineto +stroke +readpath +V0168014DAD300A8E82A8E86A8B89A898BA858DA828FA00B7A028FA058DA098BA0B89A0E86A0E82E +00A700A0E02A0E06A0B09A080BA060DA020FA0037A820FA860DA880BA8B09A8E06A8E02AD400~ +stroke +297 266 moveto +<4F415453> +[36 32 28 0] +xshow +1221 1075 moveto +1298 998 lineto +stroke +1233 1142 moveto +1377 998 lineto +stroke +1289 1165 moveto +1456 998 lineto +stroke +1368 1165 moveto +1535 998 lineto +stroke +1447 1165 moveto +1607 1005 lineto +stroke +1526 1165 moveto +1636 1055 lineto +stroke +readpath +V0594048DE809700A8F82A8E86A8B89A888BA868DA828FA00B7A028FA068DA088CA0B88A0E86A0F8 +2E012F00A0F02A0D06A0C08A080CA060DA020FA0037A820FA860DA880BA8C09A8D06A8F02E809800~ +stroke +1249 1071 moveto +<4D6F76696E672F5472616E7369656E74> +[39 26 23 11 26 26 13 29 16 25 26 24 10 26 26 0] +xshow +1249 1126 moveto +<4F626A65637420506970656C696E65> +[36 26 10 27 23 13 13 31 11 26 26 11 10 26 0] +xshow +860 1352 moveto +937 1275 lineto +stroke +872 1420 moveto +1016 1275 lineto +stroke +928 1442 moveto +1093 1277 lineto +stroke +1007 1442 moveto +1134 1315 lineto +stroke +1087 1441 moveto +1136 1392 lineto +stroke +readpath +V03E605A2AD300A8F82A8D86A8B89A898BA868DA818FA00B7A018FA068DA098BA0B89A0D86A0F82E +00A600A0F02A0D06A0B09A090BA060DA020FA0037A820FA860DA890BA8B09A8D06A8F02AD300~ +stroke +886 1375 moveto +<53414943204F4442> +[31 31 13 34 13 37 34 0] +xshow +readpath +V03E601F3E811500A8F82A8D86A8B88A898BA868EA828EA0000A028FA068DA098CA0B88A0D86A0F8 +2E022A00A0F02A0D06A0C08A080CA060DA020FA0000A820EA860EA880BA8C08A8D06A8F02E811500~ +0.6 0.6 0.6 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V03E601F3E811500A8F82A8D86A8B88A898BA868EA828EA028FA068DA098CA0B88A0D86A0F82E022 +A00A0F02A0D06A0C08A080CA060DA020FA820EA860EA880BA8C08A8D06A8F02E811500~ +stroke +688 460 moveto +<5363686564756C6572> +[31 23 27 25 26 27 10 26 0] +xshow +readpath +V020F0340A290EA009CAA90E~ +eofill +readpath +V02990340AA98EA001CA298E~ +eofill +readpath +V0230033AA4800A000BAC800A008B~ +eofill +readpath +V053301BCA1908A0091A9909~ +eofill +readpath +V05B501BCA9989A0011A1988~ +eofill +readpath +V054701BCA5A00~ +stroke +readpath +V066601F3A8819A1000A8899~ +eofill +readpath +V05330340A1908A0091A9909~ +eofill +readpath +V06660207B000139E811F00~ +stroke +readpath +V03E60377A8819A1000A8899~ +eofill +readpath +V03E603E6A0899A9000A0819~ +eofill +readpath +V03E6038BA0047~ +stroke +readpath +V016802EDA0EAAA9C00A0E2A~ +eofill +readpath +V016E014DB00017EA8B00B00817EA0B00~ +eofill +readpath +V06660184A0899A9100A0919~ +eofill +readpath +V01F300FAE047300A0076~ +stroke +readpath +V03E604FBA0899A9000A0819~ +eofill +readpath +V03E604E7A0090~ +stroke +readpath +V03E604C6A0090~ +stroke +readpath +V03E604A5A0091~ +stroke +readpath +V04C50439A9988A0011A1989~ +eofill +readpath +V04550439A1909A0091A9908~ +eofill +readpath +V04B10439AC800~ +stroke +readpath +V0471054FA1908A0091A9909~ +eofill +readpath +V071701BCA3700B000393E82C900~ +stroke +readpath +V03E601F3A8714A0E00A8794~ +0.50196 0.50196 0.50196 setrgbcolor +eofill +readpath +V03E60246A0794A8E00A0714~ +eofill +readpath +V03E60203A0033~ +stroke +readpath +V06640439A1909A0091A9908~ +0 0 0 setrgbcolor +eofill +readpath +V06C301F3B000246ACB00~ +stroke +readpath +V016804FBA0EA9A9C00A0E29~ +eofill +readpath +V016E0393A0011A8B00A0091A0B00~ +eofill +readpath +V016E03B4A0011A8B00A0091A0B00~ +eofill +readpath +V016E03D6A0010A8B00A0090A0B00~ +eofill +readpath +V016E03F7A0010A8B00A0090A0B00~ +eofill +readpath +V016E0418A0011A8B00A0091A0B00~ +eofill +readpath +V016E0439A0011A8B00A0091A0B00~ +eofill +readpath +V016E045BA0010A8B00A0090A0B00~ +eofill +readpath +V016E047CA0011A8B00A0091A0B00~ +eofill +readpath +V016E049DA0011A8B00A0091A0B00~ +eofill +readpath +V016E04BEA0011A8B00A0091A0B00~ +eofill +194 1352 moveto +271 1275 lineto +stroke +206 1419 moveto +350 1275 lineto +stroke +262 1442 moveto +429 1275 lineto +stroke +341 1442 moveto +500 1283 lineto +stroke +420 1442 moveto +527 1335 lineto +stroke +readpath +V016805A2AEE00A8F82A8E86A8B89A888BA868DA828FA00B7A028FA068DA088BA0B89A0E86A0F82E +00DD00A0F02A0D06A0B09A090BA060DA020FA0037A820FA860DA890BA8B09A8D06A8F02AEF00~ +stroke +246 1375 moveto +<536B7920536572766572> +[31 23 24 13 31 26 15 24 26 0] +xshow +readpath +V00C20340A9989A0011A1988~ +0.50196 0.50196 0.50196 setrgbcolor +eofill +readpath +V00DE00FAAEF00B000246A3F00~ +stroke +readpath +V035C054FA9A89A0111A1988~ +0 0 0 setrgbcolor +eofill +readpath +V020F054FE013900~ +stroke +readpath +V01070680AC500A8982A8784A8686A8487A8289A0000A0289A0488A0686A0784A0981E008B00A080 +1A0804A0606A0408A0109A0000A8109A8407A8606A8804A8802AC600~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V01070680AC500A8982A8784A8686A8487A8289A0289A0488A0686A0784A0981E008B00A0801A080 +4A0606A0408A0109A8109A8407A8606A8804A8802AC600~ +stroke +189 1647 moveto +/LuxiSansHSet1 findfont 31 -31 matrix scale makefont setfont +<50726F63657373696E67> +[20 10 18 15 18 15 16 6 17 0] +xshow +readpath +V0299062CE00C300A0054E80C300A00D4~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V02FA0680AE100A00D4E00C300A0054AE200~ +stroke +688 1615 moveto +<44617461> +[22 17 9 0] +xshow +688 1651 moveto +<53756273797374656D> +[20 18 16 16 15 16 9 17 0] +xshow +920 1652 moveto +992 1580 lineto +stroke +987 1664 moveto +1067 1584 lineto +stroke +readpath +V03E60680AB700A8982A8884A8686A8487A8189A009CA0189A0487A0686A0884A0982A6F00A0802A +0804A0606A0407A0109A001CA8109A8407A8606A8804A8802AB800~ +stroke +937 1615 moveto +<45787465726E616C> +[20 16 8 17 10 18 17 0] +xshow +937 1651 moveto +<53797374656D> +[20 16 15 9 17 0] +xshow +readpath +V02010680AC500A8982A8884A8686A8487A8189A0000A0189A0488A0686A0884A0981E008A00A090 +1A0804A0606A0408A0109A0000A8109A8407A8606A8804A8902AC500~ +0.6 0.6 0.6 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V02010680AC500A8982A8884A8686A8487A8189A0189A0488A0686A0884A0981E008A00A0901A080 +4A0606A0408A0109A8109A8407A8606A8804A8902AC500~ +stroke +438 1647 moveto +<5363686564756C6572> +[20 16 17 17 17 17 8 17 0] +xshow +166 1541 moveto +/LuxiSansHSet1 findfont 47 -47 matrix scale makefont setfont +<4C6567656E64> +[25 27 26 26 27 0] +xshow +readpath +V04FB05D9AB290A0121A3191~ +eofill +readpath +V047405D4A5F00A000BADF00A008B~ +eofill +readpath +V04FB0611A9989A0011A1988~ +eofill +readpath +V04710611A7600~ +stroke +readpath +V04FB0680A9487A000DA1486~ +0.50196 0.50196 0.50196 setrgbcolor +eofill +readpath +V04710680A7A00~ +stroke +readpath +V04FB0648A9988A0010A1988~ +0 0 0 setrgbcolor +eofill +readpath +V04710648A1000~ +stroke +readpath +V04920648A1100~ +stroke +readpath +V04B30648A1100~ +stroke +readpath +V04D50648A1000~ +stroke +1303 1498 moveto +/LuxiSansHSet1 findfont 31 -31 matrix scale makefont setfont +<706978656C2064617461> +[17 7 16 16 7 8 18 17 9 0] +xshow +1303 1554 moveto +<6D6574612026206F626A6563742064617461> +[25 17 9 18 8 21 8 17 18 6 17 16 9 8 18 17 8 0] +xshow +1303 1665 moveto +<636F6D6D616E64732026206D65737361676573> +[15 17 26 26 17 17 17 16 9 20 9 26 17 15 16 17 18 17 0] +xshow +1303 1609 moveto +<72657669657765642064617461> +[9 18 15 8 17 22 17 18 8 17 17 10 0] +xshow +readpath +V03E60377E811500A8F82A8D85A8B89A898BA868EA828EA0000A028FA068DA098BA0B89A0D86A0F8 +2E022A00A0F02A0D06A0C09A080BA060DA020FA0000A820EA860EA880BA8C09A8D05A8F02E811500~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V03E60377E811500A8F82A8D85A8B89A898BA868EA828EA028FA068DA098BA0B89A0D86A0F82E022 +A00A0F02A0D06A0C09A080BA060DA020FA820EA860EA880BA8C09A8D05A8F02E811500~ +stroke +688 849 moveto +/LuxiSansHSet1 findfont 47 -47 matrix scale makefont setfont +<50726F63657373696E67204A6F6273> +[31 15 26 24 26 23 24 10 27 26 13 23 26 26 0] +xshow +readpath +V03E602B5A8714A0E00A8794~ +0.50196 0.50196 0.50196 setrgbcolor +eofill +readpath +V03E60308A0794A8E00A0714~ +eofill +readpath +V03E602C5A0033~ +stroke +grestore grestore Index: /trunk/doc/design/pics/overview.ps~ =================================================================== --- /trunk/doc/design/pics/overview.ps~ (revision 409) +++ /trunk/doc/design/pics/overview.ps~ (revision 409) @@ -0,0 +1,1409 @@ +%!PS-Adobe-2.0 EPSF-1.2 +%%Title: dataflow.sxd +%%Creator: OpenOffice.org 1.0.2 +%%CreationDate: Thu Mar 4 15:42:25 2004 +%%For: eugene +%%Pages: 1 +%%DocumentFonts: LuxiSansHSet1 +%%BoundingBox: 44 422 467 785 +%%EndProlog +%%Page: 1 1 +%%BeginDocument: /tmp/eps.oT7Rao +/ISO1252Encoding [ +/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef +/.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef /.notdef +/space /exclam /quotedbl /numbersign /dollar /percent /ampersand /quotesingle +/parenleft /parenright /asterisk /plus /comma /hyphen /period /slash +/zero /one /two /three /four /five /six /seven +/eight /nine /colon /semicolon /less /equal /greater /question +/at /A /B /C /D /E /F /G +/H /I /J /K /L /M /N /O +/P /Q /R /S /T /U /V /W +/X /Y /Z /bracketleft /backslash /bracketright /asciicircum /underscore +/grave /a /b /c /d /e /f /g +/h /i /j /k /l /m /n /o +/p /q /r /s /t /u /v /w +/x /y /z /braceleft /bar /braceright /asciitilde /unused +/Euro /unused /quotesinglbase /florin /quotedblbase /ellipsis /dagger /daggerdbl +/circumflex /perthousand /Scaron /guilsinglleft /OE /unused /Zcaron /unused +/unused /quoteleft /quoteright /quotedblleft /quotedblright /bullet /endash /emdash +/tilde /trademark /scaron /guilsinglright /oe /unused /zcaron /Ydieresis +/space /exclamdown /cent /sterling /currency /yen /brokenbar /section +/dieresis /copyright /ordfeminine /guillemotleft /logicalnot /hyphen /registered /macron +/degree /plusminus /twosuperior /threesuperior /acute /mu /paragraph /periodcentered +/cedilla /onesuperior /ordmasculine /guillemotright /onequarter /onehalf /threequarters /questiondown +/Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring /AE /Ccedilla +/Egrave /Eacute /Ecircumflex /Edieresis /Igrave /Iacute /Icircumflex /Idieresis +/Eth /Ntilde /Ograve /Oacute /Ocircumflex /Otilde /Odieresis /multiply +/Oslash /Ugrave /Uacute /Ucircumflex /Udieresis /Yacute /Thorn /germandbls +/agrave /aacute /acircumflex /atilde /adieresis /aring /ae /ccedilla +/egrave /eacute /ecircumflex /edieresis /igrave /iacute /icircumflex /idieresis +/eth /ntilde /ograve /oacute /ocircumflex /otilde /odieresis /divide +/oslash /ugrave /uacute /ucircumflex /udieresis /yacute /thorn /ydieresis] def + +/psp_definefont { exch dup findfont dup length dict begin { 1 index /FID ne +{ def } { pop pop } ifelse } forall /Encoding 3 -1 roll def +currentdict end exch pop definefont pop } def + +/pathdict dup 8 dict def load begin +/rcmd { { currentfile 1 string readstring pop 0 get dup 32 gt { exit } +{ pop } ifelse } loop dup 126 eq { pop exit } if 65 sub dup 16#3 and 1 +add exch dup 16#C and -2 bitshift 16#3 and 1 add exch 16#10 and 16#10 +eq 3 1 roll exch } def +/rhex { dup 1 sub exch currentfile exch string readhexstring pop dup 0 +get dup 16#80 and 16#80 eq dup 3 1 roll { 16#7f and } if 2 index 0 3 +-1 roll put 3 1 roll 0 0 1 5 -1 roll { 2 index exch get add 256 mul } +for 256 div exch pop exch { neg } if } def +/xcmd { rcmd exch rhex exch rhex exch 5 -1 roll add exch 4 -1 roll add +1 index 1 index 5 -1 roll { moveto } { lineto } ifelse } def end +/readpath { 0 0 pathdict begin { xcmd } loop end pop pop } def + +systemdict /languagelevel known not { +/xshow { exch dup length 0 1 3 -1 roll 1 sub { dup 3 index exch get +exch 2 index exch get 1 string dup 0 4 -1 roll put currentpoint 3 -1 +roll show moveto 0 rmoveto } for pop pop } def +/rectangle { 4 -2 roll moveto 1 index 0 rlineto 0 exch rlineto neg 0 +rlineto closepath } def +/rectfill { rectangle fill } def +/rectstroke { rectangle stroke } def } if + +/psp_lzwfilter { currentfile /ASCII85Decode filter /LZWDecode filter } def +/psp_ascii85filter { currentfile /ASCII85Decode filter } def +/psp_lzwstring { psp_lzwfilter 1024 string readstring } def +/psp_ascii85string { psp_ascii85filter 1024 string readstring } def +/psp_imagedict { +/psp_bitspercomponent { 3 eq { 1 }{ 8 } ifelse } def +/psp_decodearray { [ [0 1 0 1 0 1] [0 255] [0 1] [0 255] ] exch get } +def 7 dict dup +/ImageType 1 put dup +/Width 7 -1 roll put dup +/Height 5 index put dup +/BitsPerComponent 4 index psp_bitspercomponent put dup +/Decode 5 -1 roll psp_decodearray put dup +/ImageMatrix [1 0 0 1 0 0] dup 5 8 -1 roll put put dup +/DataSource 4 -1 roll 1 eq { psp_lzwfilter } { psp_ascii85filter } ifelse put +} def +% +% +gsave +[0.24 0 0 -0.24 18 824] concat +gsave +% Original font name: LuxiSans +30 dict begin +/PaintType 0 def +/FontType 3 def +/StrokeWidth 0 def +/FontName /LuxiSansHSet1 def +/XUID [103 0 0 16#76C7BB62 39 16#530C6258 16#E084E573] def +/FontMatrix [.001 0 0 .001 0 0] def +/FontBBox [-215 -210 988 992] def +/Encoding 256 array def + 0 1 255 {Encoding exch /.notdef put} for + Encoding 32 /glyph0 put + Encoding 38 /glyph1 put + Encoding 47 /glyph2 put + Encoding 65 /glyph3 put + Encoding 66 /glyph4 put + Encoding 67 /glyph5 put + Encoding 68 /glyph6 put + Encoding 69 /glyph7 put + Encoding 73 /glyph8 put + Encoding 74 /glyph9 put + Encoding 76 /glyph10 put + Encoding 77 /glyph11 put + Encoding 79 /glyph12 put + Encoding 80 /glyph13 put + Encoding 83 /glyph14 put + Encoding 84 /glyph15 put + Encoding 97 /glyph16 put + Encoding 98 /glyph17 put + Encoding 99 /glyph18 put + Encoding 100 /glyph19 put + Encoding 101 /glyph20 put + Encoding 103 /glyph21 put + Encoding 104 /glyph22 put + Encoding 105 /glyph23 put + Encoding 106 /glyph24 put + Encoding 107 /glyph25 put + Encoding 108 /glyph26 put + Encoding 109 /glyph27 put + Encoding 110 /glyph28 put + Encoding 111 /glyph29 put + Encoding 112 /glyph30 put + Encoding 114 /glyph31 put + Encoding 115 /glyph32 put + Encoding 116 /glyph33 put + Encoding 117 /glyph34 put + Encoding 118 /glyph35 put + Encoding 119 /glyph36 put + Encoding 120 /glyph37 put + Encoding 121 /glyph38 put +/CharProcs 40 dict def + CharProcs begin + /.notdef {} def + /glyph0 { + 277 0 0 0 0 0 setcachedevice + } bind def + /glyph1 { + 666 0 27 -18 631 740 setcachedevice + 500 0 moveto + 464 42 lineto + 399 2 337 -18 278 -18 curveto + 207 -18 147 3 99 48 curveto + 51 92 27 148 27 215 curveto + 27 282 48 336 90 377 curveto + 115 401 150 423 197 441 curveto + 169 494 154 540 154 579 curveto + 154 628 169 667 199 696 curveto + 229 726 270 740 321 740 curveto + 370 740 408 728 437 701 curveto + 465 675 479 639 479 595 curveto + 479 546 460 503 422 468 curveto + 399 447 366 426 322 406 curveto + 377 307 431 225 485 160 curveto + 518 201 534 263 534 345 curveto + 534 384 lineto + 629 384 lineto + 629 271 596 179 530 107 curveto + 559 71 592 35 631 0 curveto + 500 0 lineto + closepath + 422 98 moveto + 358 171 295 267 231 385 curveto + 200 370 176 353 159 333 curveto + 136 307 124 273 124 232 curveto + 124 183 140 141 173 106 curveto + 207 71 247 54 293 54 curveto + 330 54 373 68 422 98 curveto + closepath + 286 466 moveto + 317 480 340 495 355 510 curveto + 377 533 389 561 389 593 curveto + 389 643 366 668 320 668 curveto + 272 668 248 642 248 589 curveto + 248 557 259 519 282 474 curveto + 286 466 lineto + closepath + fill + } bind def + /glyph2 { + 277 0 -28 -144 307 722 setcachedevice + -28 -144 moveto + 231 722 lineto + 307 722 lineto + 46 -144 lineto + -28 -144 lineto + closepath + fill + } bind def + /glyph3 { + 666 0 9 0 655 722 setcachedevice + 9 0 moveto + 283 722 lineto + 385 722 lineto + 655 0 lineto + 544 0 lineto + 469 200 lineto + 179 200 lineto + 104 0 lineto + 9 0 lineto + closepath + 208 276 moveto + 441 276 lineto + 325 585 lineto + 208 276 lineto + closepath + fill + } bind def + /glyph4 { + 666 0 80 0 601 722 setcachedevice + 80 0 moveto + 80 722 lineto + 312 722 lineto + 407 722 474 710 513 686 curveto + 552 661 572 620 572 561 curveto + 572 507 553 463 514 429 curveto + 491 409 457 392 412 376 curveto + 468 359 511 339 540 314 curveto + 580 280 601 235 601 180 curveto + 601 129 584 86 551 52 curveto + 528 28 497 13 458 7 curveto + 429 2 388 0 337 0 curveto + 80 0 lineto + closepath + 183 76 moveto + 258 76 lineto + 354 76 417 83 447 98 curveto + 477 112 492 141 492 187 curveto + 492 236 473 274 434 300 curveto + 395 327 340 340 266 340 curveto + 183 340 lineto + 183 76 lineto + closepath + 183 405 moveto + 270 405 lineto + 401 405 466 451 466 543 curveto + 466 589 448 619 410 631 curveto + 382 641 337 645 277 645 curveto + 183 645 lineto + 183 405 lineto + closepath + fill + } bind def + /glyph5 { + 722 0 56 -18 660 740 setcachedevice + 660 37 moveto + 585 0 506 -18 420 -18 curveto + 302 -18 211 14 149 78 curveto + 87 143 56 236 56 360 curveto + 56 483 88 577 151 643 curveto + 214 708 305 740 425 740 curveto + 492 740 569 730 659 708 curveto + 659 612 lineto + 558 646 478 664 419 664 curveto + 338 664 275 638 231 585 curveto + 188 534 166 459 166 361 curveto + 166 266 189 192 236 140 curveto + 282 88 348 62 432 62 curveto + 503 62 579 83 660 125 curveto + 660 37 lineto + closepath + fill + } bind def + /glyph6 { + 722 0 80 0 676 722 setcachedevice + 80 0 moveto + 80 722 lineto + 312 722 lineto + 555 722 676 607 676 377 curveto + 676 258 645 165 581 99 curveto + 518 33 429 0 313 0 curveto + 80 0 lineto + closepath + 183 76 moveto + 306 76 lineto + 479 76 566 173 566 366 curveto + 566 479 532 560 463 606 curveto + 443 620 419 629 392 635 curveto + 358 642 314 645 258 645 curveto + 183 645 lineto + 183 76 lineto + closepath + fill + } bind def + /glyph7 { + 666 0 93 0 638 722 setcachedevice + 93 0 moveto + 93 722 lineto + 617 722 lineto + 617 645 lineto + 195 645 lineto + 195 414 lineto + 568 414 lineto + 568 338 lineto + 195 338 lineto + 195 76 lineto + 638 76 lineto + 638 0 lineto + 93 0 lineto + closepath + fill + } bind def + /glyph8 { + 277 0 87 0 190 722 setcachedevice + 87 0 moveto + 87 722 lineto + 190 722 lineto + 190 0 lineto + 87 0 lineto + closepath + fill + } bind def + /glyph9 { + 500 0 23 -144 410 722 setcachedevice + 23 -113 moveto + 23 -24 lineto + 79 -49 131 -62 180 -62 curveto + 235 -62 271 -49 287 -23 curveto + 300 -1 307 35 307 87 curveto + 307 722 lineto + 410 722 lineto + 410 91 lineto + 410 -65 332 -144 175 -144 curveto + 123 -144 72 -134 23 -113 curveto + closepath + fill + } bind def + /glyph10 { + 556 0 80 0 537 722 setcachedevice + 80 0 moveto + 80 722 lineto + 183 722 lineto + 183 76 lineto + 537 76 lineto + 537 0 lineto + 80 0 lineto + closepath + fill + } bind def + /glyph11 { + 833 0 80 0 752 722 setcachedevice + 80 0 moveto + 80 722 lineto + 222 722 lineto + 421 163 lineto + 625 722 lineto + 752 722 lineto + 752 0 lineto + 656 0 lineto + 656 587 lineto + 459 48 lineto + 360 48 lineto + 168 589 lineto + 168 0 lineto + 80 0 lineto + closepath + fill + } bind def + /glyph12 { + 777 0 45 -18 732 740 setcachedevice + 389 740 moveto + 493 740 576 706 639 637 curveto + 701 568 732 477 732 362 curveto + 732 245 702 153 639 84 curveto + 576 16 491 -18 384 -18 curveto + 292 -18 217 10 157 66 curveto + 83 137 45 235 45 361 curveto + 45 477 76 568 139 637 curveto + 201 706 285 740 389 740 curveto + closepath + 389 664 moveto + 315 664 258 637 216 584 curveto + 176 531 155 457 155 361 curveto + 155 267 175 193 216 139 curveto + 257 85 313 58 386 58 curveto + 454 58 507 80 547 123 curveto + 598 176 623 255 623 362 curveto + 623 457 602 531 561 584 curveto + 520 637 462 664 389 664 curveto + closepath + fill + } bind def + /glyph13 { + 666 0 81 0 643 722 setcachedevice + 81 0 moveto + 81 722 lineto + 364 722 lineto + 439 722 492 718 524 709 curveto + 557 701 584 684 604 659 curveto + 630 628 643 585 643 531 curveto + 643 369 541 287 334 287 curveto + 184 287 lineto + 184 0 lineto + 81 0 lineto + closepath + 184 364 moveto + 330 364 lineto + 466 364 535 418 535 525 curveto + 535 577 517 611 481 626 curveto + 452 639 402 645 332 645 curveto + 184 645 lineto + 184 364 lineto + closepath + fill + } bind def + /glyph14 { + 666 0 58 -18 606 740 setcachedevice + 58 25 moveto + 58 126 lineto + 154 81 250 58 343 58 curveto + 448 58 501 97 501 175 curveto + 501 215 487 245 458 264 curveto + 436 279 399 294 349 311 curveto + 251 343 lineto + 125 384 62 452 62 547 curveto + 62 676 150 740 327 740 curveto + 402 740 480 730 562 709 curveto + 562 615 lineto + 477 647 397 664 320 664 curveto + 214 664 161 628 161 555 curveto + 161 527 171 504 191 487 curveto + 211 469 248 452 299 435 curveto + 400 402 lineto + 476 377 529 349 560 317 curveto + 591 286 606 243 606 190 curveto + 606 126 583 75 535 38 curveto + 488 0 423 -18 339 -18 curveto + 258 -18 164 -3 58 25 curveto + closepath + fill + } bind def + /glyph15 { + 610 0 9 0 600 722 setcachedevice + 253 0 moveto + 253 645 lineto + 9 645 lineto + 9 722 lineto + 600 722 lineto + 600 645 lineto + 356 645 lineto + 356 0 lineto + 253 0 lineto + closepath + fill + } bind def + /glyph16 { + 556 0 46 -12 536 541 setcachedevice + 377 67 moveto + 317 14 259 -12 202 -12 curveto + 156 -12 119 1 89 28 curveto + 61 55 46 90 46 133 curveto + 46 253 144 313 341 313 curveto + 363 313 lineto + 363 377 lineto + 363 438 330 469 261 469 curveto + 209 469 152 454 92 422 curveto + 92 502 lineto + 159 528 221 541 280 541 curveto + 342 541 388 529 416 502 curveto + 445 476 459 435 459 377 curveto + 459 137 lineto + 459 82 477 54 510 54 curveto + 515 54 521 55 529 56 curveto + 536 3 lineto + 512 -6 488 -12 464 -12 curveto + 442 -12 424 -5 410 6 curveto + 396 18 385 38 377 67 curveto + closepath + 363 119 moveto + 363 256 lineto + 332 257 lineto + 312 258 291 257 267 253 curveto + 186 242 145 207 145 147 curveto + 145 93 175 66 234 66 curveto + 275 66 318 83 363 119 curveto + closepath + fill + } bind def + /glyph17 { + 556 0 75 -12 513 770 setcachedevice + 171 343 moveto + 171 72 lineto + 215 64 249 60 271 60 curveto + 363 60 409 129 409 269 curveto + 409 328 400 374 382 407 curveto + 364 441 340 458 309 458 curveto + 269 458 222 419 171 343 curveto + closepath + 171 430 moveto + 189 463 208 488 229 505 curveto + 257 529 291 541 330 541 curveto + 385 541 429 518 462 470 curveto + 496 422 513 358 513 279 curveto + 513 187 492 115 448 63 curveto + 405 13 343 -12 263 -12 curveto + 234 -12 203 -8 171 0 curveto + 75 -5 lineto + 75 770 lineto + 171 770 lineto + 171 430 lineto + closepath + fill + } bind def + /glyph18 { + 500 0 41 -12 452 541 setcachedevice + 452 16 moveto + 393 -2 337 -12 285 -12 curveto + 212 -12 153 13 108 64 curveto + 64 116 41 182 41 265 curveto + 41 351 64 419 110 468 curveto + 155 517 219 541 300 541 curveto + 341 541 390 536 446 524 curveto + 446 444 lineto + 393 460 350 468 318 468 curveto + 206 468 150 400 150 265 curveto + 150 201 165 152 193 117 curveto + 222 83 262 65 314 65 curveto + 354 65 399 76 452 99 curveto + 452 16 lineto + closepath + fill + } bind def + /glyph19 { + 556 0 41 -12 480 770 setcachedevice + 384 186 moveto + 384 457 lineto + 339 465 306 469 284 469 curveto + 192 469 145 399 145 259 curveto + 145 202 155 156 173 122 curveto + 191 89 215 72 246 72 curveto + 287 72 333 110 384 186 curveto + closepath + 384 99 moveto + 366 66 347 41 326 23 curveto + 298 0 264 -12 225 -12 curveto + 170 -12 126 11 92 60 curveto + 59 107 41 171 41 250 curveto + 41 343 63 415 107 465 curveto + 150 516 212 541 291 541 curveto + 322 541 353 538 384 530 curveto + 384 770 lineto + 480 770 lineto + 480 0 lineto + 384 0 lineto + 384 99 lineto + closepath + fill + } bind def + /glyph20 { + 556 0 41 -12 499 541 setcachedevice + 399 322 moveto + 398 354 395 378 389 395 curveto + 373 445 336 470 279 470 curveto + 240 470 208 458 186 435 curveto + 164 413 150 375 144 322 curveto + 399 322 lineto + closepath + 494 93 moveto + 494 17 lineto + 428 -1 368 -12 312 -12 curveto + 230 -12 164 13 115 64 curveto + 66 116 41 185 41 271 curveto + 41 354 63 419 106 468 curveto + 149 517 208 541 281 541 curveto + 366 541 425 512 460 452 curveto + 486 407 499 350 497 279 curveto + 497 250 lineto + 143 250 lineto + 146 211 153 182 162 161 curveto + 190 94 248 61 333 61 curveto + 381 61 435 71 494 93 curveto + closepath + fill + } bind def + /glyph21 { + 556 0 45 -205 483 541 setcachedevice + 387 210 moveto + 387 457 lineto + 342 465 309 469 288 469 curveto + 196 469 149 406 149 280 curveto + 149 224 158 179 176 145 curveto + 194 113 219 96 249 96 curveto + 290 96 336 134 387 210 curveto + closepath + 387 123 moveto + 370 90 351 65 330 48 curveto + 301 24 268 12 229 12 curveto + 175 12 130 36 96 83 curveto + 62 130 45 192 45 269 curveto + 45 355 67 422 110 470 curveto + 154 518 215 541 294 541 curveto + 325 541 355 538 387 530 curveto + 483 530 lineto + 483 144 lineto + 483 61 479 0 470 -40 curveto + 447 -149 365 -205 226 -205 curveto + 167 -205 108 -195 48 -176 curveto + 48 -92 lineto + 118 -118 177 -132 225 -132 curveto + 333 -132 387 -74 387 40 curveto + 387 123 lineto + closepath + fill + } bind def + /glyph22 { + 556 0 75 0 486 770 setcachedevice + 75 0 moveto + 75 770 lineto + 171 770 lineto + 171 430 lineto + 195 463 218 488 241 505 curveto + 275 529 312 541 352 541 curveto + 441 541 486 488 486 380 curveto + 486 0 lineto + 390 0 lineto + 390 349 lineto + 390 392 386 421 376 436 curveto + 368 451 351 459 326 459 curveto + 273 459 222 420 171 343 curveto + 171 0 lineto + 75 0 lineto + closepath + fill + } bind def + /glyph23 { + 222 0 62 0 159 722 setcachedevice + 62 0 moveto + 62 530 lineto + 159 530 lineto + 159 0 lineto + 62 0 lineto + closepath + 62 626 moveto + 62 722 lineto + 159 722 lineto + 159 626 lineto + 62 626 lineto + closepath + fill + } bind def + /glyph24 { + 222 0 -75 -204 161 722 setcachedevice + -75 -188 moveto + -75 -112 lineto + -49 -125 -25 -132 -2 -132 curveto + 29 -132 48 -120 56 -96 curveto + 62 -76 64 -44 64 0 curveto + 64 530 lineto + 161 530 lineto + 161 0 lineto + 161 -136 109 -204 5 -204 curveto + -22 -204 -49 -199 -75 -188 curveto + closepath + 64 626 moveto + 64 722 lineto + 161 722 lineto + 161 626 lineto + 64 626 lineto + closepath + fill + } bind def + /glyph25 { + 500 0 75 0 491 770 setcachedevice + 75 0 moveto + 75 770 lineto + 171 770 lineto + 171 272 lineto + 349 530 lineto + 440 530 lineto + 271 279 lineto + 491 0 lineto + 374 0 lineto + 171 271 lineto + 171 0 lineto + 75 0 lineto + closepath + fill + } bind def + /glyph26 { + 222 0 62 0 159 770 setcachedevice + 62 0 moveto + 62 770 lineto + 159 770 lineto + 159 0 lineto + 62 0 lineto + closepath + fill + } bind def + /glyph27 { + 833 0 75 0 763 541 setcachedevice + 75 0 moveto + 75 530 lineto + 171 530 lineto + 171 430 lineto + 199 473 223 501 241 516 curveto + 262 533 290 541 324 541 curveto + 367 541 401 528 427 500 curveto + 442 485 456 461 467 430 curveto + 496 473 519 502 537 516 curveto + 558 533 586 541 621 541 curveto + 716 541 763 490 763 385 curveto + 763 0 lineto + 667 0 lineto + 666 370 lineto + 666 431 644 461 596 461 curveto + 555 461 512 426 467 355 curveto + 467 0 lineto + 371 0 lineto + 371 370 lineto + 371 431 347 461 300 461 curveto + 258 461 215 426 171 355 curveto + 171 0 lineto + 75 0 lineto + closepath + fill + } bind def + /glyph28 { + 556 0 75 0 486 541 setcachedevice + 75 0 moveto + 75 530 lineto + 171 530 lineto + 171 430 lineto + 195 463 218 488 241 505 curveto + 275 529 312 541 352 541 curveto + 441 541 486 488 486 380 curveto + 486 0 lineto + 390 0 lineto + 390 349 lineto + 390 392 386 421 376 436 curveto + 368 451 351 459 326 459 curveto + 273 459 222 420 171 343 curveto + 171 0 lineto + 75 0 lineto + closepath + fill + } bind def + /glyph29 { + 556 0 41 -12 513 541 setcachedevice + 277 541 moveto + 350 541 407 517 450 467 curveto + 492 418 513 351 513 265 curveto + 513 179 492 110 450 61 curveto + 408 12 349 -12 274 -12 curveto + 210 -12 158 8 118 48 curveto + 67 100 41 171 41 265 curveto + 41 350 62 418 105 467 curveto + 147 517 205 541 277 541 curveto + closepath + 277 469 moveto + 190 469 145 401 145 265 curveto + 145 128 189 60 277 60 curveto + 365 60 409 128 409 267 curveto + 409 402 366 469 277 469 curveto + closepath + fill + } bind def + /glyph30 { + 556 0 75 -192 513 541 setcachedevice + 171 -192 moveto + 75 -192 lineto + 75 530 lineto + 171 530 lineto + 171 430 lineto + 189 463 208 488 229 505 curveto + 257 529 291 541 330 541 curveto + 385 541 429 518 462 470 curveto + 496 422 513 358 513 279 curveto + 513 187 492 115 448 63 curveto + 405 13 343 -12 263 -12 curveto + 234 -12 203 -8 171 0 curveto + 171 -192 lineto + closepath + 171 343 moveto + 171 72 lineto + 215 64 249 60 271 60 curveto + 363 60 409 129 409 269 curveto + 409 328 400 374 382 407 curveto + 364 441 340 458 309 458 curveto + 269 458 222 419 171 343 curveto + closepath + fill + } bind def + /glyph31 { + 333 0 75 0 326 541 setcachedevice + 75 0 moveto + 75 530 lineto + 171 530 lineto + 171 430 lineto + 185 464 200 489 216 505 curveto + 239 529 267 541 298 541 curveto + 305 541 313 541 326 539 curveto + 326 449 lineto + 309 455 295 458 285 458 curveto + 250 458 211 422 171 349 curveto + 171 0 lineto + 75 0 lineto + closepath + fill + } bind def + /glyph32 { + 500 0 56 -12 443 541 setcachedevice + 56 18 moveto + 56 106 lineto + 121 76 181 60 235 60 curveto + 309 60 346 85 346 138 curveto + 346 173 321 200 269 217 curveto + 183 245 lineto + 101 272 59 322 59 394 curveto + 59 492 126 541 261 541 curveto + 300 541 347 537 402 526 curveto + 402 445 lineto + 354 461 304 469 255 469 curveto + 188 469 154 448 154 403 curveto + 154 372 177 348 223 333 curveto + 300 308 lineto + 395 277 443 224 443 147 curveto + 443 98 424 59 386 30 curveto + 349 2 297 -12 231 -12 curveto + 180 -12 122 -1 56 18 curveto + closepath + fill + } bind def + /glyph33 { + 277 0 14 -12 272 635 setcachedevice + 258 -2 moveto + 239 -8 221 -12 203 -12 curveto + 117 -12 74 40 74 146 curveto + 74 458 lineto + 14 458 lineto + 14 530 lineto + 74 530 lineto + 74 626 lineto + 170 635 lineto + 170 530 lineto + 272 530 lineto + 272 458 lineto + 170 458 lineto + 170 164 lineto + 170 122 173 94 181 80 curveto + 188 67 203 60 226 60 curveto + 238 60 249 62 258 65 curveto + 258 -2 lineto + closepath + fill + } bind def + /glyph34 { + 556 0 69 -12 480 530 setcachedevice + 384 0 moveto + 384 99 lineto + 360 66 337 41 314 24 curveto + 281 0 244 -12 204 -12 curveto + 114 -12 69 41 69 149 curveto + 69 530 lineto + 165 530 lineto + 165 180 lineto + 165 138 169 109 178 93 curveto + 187 78 204 70 229 70 curveto + 282 70 333 109 384 186 curveto + 384 530 lineto + 480 530 lineto + 480 0 lineto + 384 0 lineto + closepath + fill + } bind def + /glyph35 { + 500 0 9 0 494 530 setcachedevice + 197 0 moveto + 9 530 lineto + 106 530 lineto + 253 117 lineto + 408 530 lineto + 494 530 lineto + 293 0 lineto + 197 0 lineto + closepath + fill + } bind def + /glyph36 { + 722 0 5 0 715 530 setcachedevice + 133 0 moveto + 5 530 lineto + 99 530 lineto + 195 130 lineto + 317 530 lineto + 413 530 lineto + 520 129 lineto + 632 530 lineto + 715 530 lineto + 566 0 lineto + 469 0 lineto + 357 410 lineto + 230 0 lineto + 133 0 lineto + closepath + fill + } bind def + /glyph37 { + 500 0 13 0 484 530 setcachedevice + 13 0 moveto + 186 280 lineto + 19 530 lineto + 130 530 lineto + 263 331 lineto + 382 530 lineto + 471 530 lineto + 309 263 lineto + 484 0 lineto + 374 0 lineto + 230 212 lineto + 102 0 lineto + 13 0 lineto + closepath + fill + } bind def + /glyph38 { + 500 0 9 -192 494 530 setcachedevice + 197 0 moveto + 9 530 lineto + 106 530 lineto + 250 123 lineto + 409 530 lineto + 494 530 lineto + 213 -192 lineto + 113 -192 lineto + 197 0 lineto + closepath + fill + } bind def + end +/BuildGlyph { + exch /CharProcs get exch + 2 copy known not + {pop /.notdef} if + get exec +} bind def +/BuildChar { + 1 index /Encoding get exch get + 1 index /BuildGlyph get exec +} bind def +currentdict end +/LuxiSansHSet1 exch definefont pop +readpath +V00C202EDE014D00B0000A6E814D00B0080A6~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +1 setlinewidth +readpath +V01680393E80A600B0080A6E014D00B0000A6E80A700~ +stroke +241 849 moveto +/LuxiSansHSet1 findfont 47 -47 matrix scale makefont setfont +<506978656C536572766572> +[31 10 24 26 10 31 27 16 23 25 0] +xshow +readpath +V05B50184E016200A006FE816200A00EF~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V066601F3E80B100A00EFE016200A006FE80B100~ +stroke +1508 460 moveto +<4D657461646174614442> +[38 27 13 26 26 26 13 26 34 0] +xshow +readpath +V037703E6E00DE00B0000A7E80DE00B0080A7~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V03E6048DAEF00B0080A7E00DE00B0000A7AEF00~ +stroke +929 1098 moveto +<4F626A4442> +[36 26 10 34 0] +xshow +readpath +V03E602B5E811500A8F82A8D85A8B89A898BA868EA828EA0000A028FA068DA098CA0B88A0D86A0F8 +2E022A00A0F02A0D06A0C08A080CA060DA020FA0000A820EA860EA880BA8C09A8D05A8F02E811500~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V03E602B5E811500A8F82A8D85A8B89A898BA868EA828EA028FA068DA098CA0B88A0D86A0F82E022 +A00A0F02A0D06A0C08A080CA060DA020FA820EA860EA880BA8C09A8D05A8F02E811500~ +stroke +688 655 moveto +<436F6E74726F6C6C6572> +[34 25 26 14 16 26 10 10 27 0] +xshow +222 243 moveto +299 166 lineto +stroke +234 311 moveto +378 166 lineto +stroke +290 333 moveto +455 168 lineto +stroke +369 333 moveto +496 206 lineto +stroke +449 332 moveto +498 283 lineto +stroke +readpath +V0168014DAD300A8E82A8E86A8B89A898BA858DA828FA00B7A028FA058DA098BA0B89A0E86A0E82E +00A700A0E02A0E06A0B09A080BA060DA020FA0037A820FA860DA880BA8B09A8E06A8E02AD400~ +stroke +297 266 moveto +<4F415453> +[36 32 28 0] +xshow +1221 1075 moveto +1298 998 lineto +stroke +1233 1142 moveto +1377 998 lineto +stroke +1289 1165 moveto +1456 998 lineto +stroke +1368 1165 moveto +1535 998 lineto +stroke +1447 1165 moveto +1607 1005 lineto +stroke +1526 1165 moveto +1636 1055 lineto +stroke +readpath +V0594048DE809700A8F82A8E86A8B89A888BA868DA828FA00B7A028FA068DA088CA0B88A0E86A0F8 +2E012F00A0F02A0D06A0C08A080CA060DA020FA0037A820FA860DA880BA8C09A8D06A8F02E809800~ +stroke +1249 1071 moveto +<4D6F76696E672F5472616E7369656E74> +[39 26 23 11 26 26 13 29 16 25 26 24 10 26 26 0] +xshow +1249 1126 moveto +<4F626A65637420506970656C696E65> +[36 26 10 27 23 13 13 31 11 26 26 11 10 26 0] +xshow +860 1352 moveto +937 1275 lineto +stroke +872 1420 moveto +1016 1275 lineto +stroke +928 1442 moveto +1093 1277 lineto +stroke +1007 1442 moveto +1134 1315 lineto +stroke +1087 1441 moveto +1136 1392 lineto +stroke +readpath +V03E605A2AD300A8F82A8D86A8B89A898BA868DA818FA00B7A018FA068DA098BA0B89A0D86A0F82E +00A600A0F02A0D06A0B09A090BA060DA020FA0037A820FA860DA890BA8B09A8D06A8F02AD300~ +stroke +886 1375 moveto +<53414943204F4442> +[31 31 13 34 13 37 34 0] +xshow +readpath +V03E601F3E811500A8F82A8D86A8B88A898BA868EA828EA0000A028FA068DA098CA0B88A0D86A0F8 +2E022A00A0F02A0D06A0C08A080CA060DA020FA0000A820EA860EA880BA8C08A8D06A8F02E811500~ +0.6 0.6 0.6 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V03E601F3E811500A8F82A8D86A8B88A898BA868EA828EA028FA068DA098CA0B88A0D86A0F82E022 +A00A0F02A0D06A0C08A080CA060DA020FA820EA860EA880BA8C08A8D06A8F02E811500~ +stroke +688 460 moveto +<5363686564756C6572> +[31 23 27 25 26 27 10 26 0] +xshow +readpath +V020F0340A290EA009CAA90E~ +eofill +readpath +V02990340AA98EA001CA298E~ +eofill +readpath +V0230033AA4800A000BAC800A008B~ +eofill +readpath +V053301BCA1908A0091A9909~ +eofill +readpath +V05B501BCA9989A0011A1988~ +eofill +readpath +V054701BCA5A00~ +stroke +readpath +V066601F3A8819A1000A8899~ +eofill +readpath +V05330340A1908A0091A9909~ +eofill +readpath +V06660207B000139E811F00~ +stroke +readpath +V03E60377A8819A1000A8899~ +eofill +readpath +V03E603E6A0899A9000A0819~ +eofill +readpath +V03E6038BA0047~ +stroke +readpath +V016802EDA0EAAA9C00A0E2A~ +eofill +readpath +V016E014DB00017EA8B00B00817EA0B00~ +eofill +readpath +V06660184A0899A9100A0919~ +eofill +readpath +V01F300FAE047300A0076~ +stroke +readpath +V03E604FBA0899A9000A0819~ +eofill +readpath +V03E604E7A0090~ +stroke +readpath +V03E604C6A0090~ +stroke +readpath +V03E604A5A0091~ +stroke +readpath +V04C50439A9988A0011A1989~ +eofill +readpath +V04550439A1909A0091A9908~ +eofill +readpath +V04B10439AC800~ +stroke +readpath +V0471054FA1908A0091A9909~ +eofill +readpath +V071701BCA3700B000393E82C900~ +stroke +readpath +V03E601F3A8714A0E00A8794~ +0.50196 0.50196 0.50196 setrgbcolor +eofill +readpath +V03E60246A0794A8E00A0714~ +eofill +readpath +V03E60203A0033~ +stroke +readpath +V06640439A1909A0091A9908~ +0 0 0 setrgbcolor +eofill +readpath +V06C301F3B000246ACB00~ +stroke +readpath +V016804FBA0EA9A9C00A0E29~ +eofill +readpath +V016E0393A0011A8B00A0091A0B00~ +eofill +readpath +V016E03B4A0011A8B00A0091A0B00~ +eofill +readpath +V016E03D6A0010A8B00A0090A0B00~ +eofill +readpath +V016E03F7A0010A8B00A0090A0B00~ +eofill +readpath +V016E0418A0011A8B00A0091A0B00~ +eofill +readpath +V016E0439A0011A8B00A0091A0B00~ +eofill +readpath +V016E045BA0010A8B00A0090A0B00~ +eofill +readpath +V016E047CA0011A8B00A0091A0B00~ +eofill +readpath +V016E049DA0011A8B00A0091A0B00~ +eofill +readpath +V016E04BEA0011A8B00A0091A0B00~ +eofill +194 1352 moveto +271 1275 lineto +stroke +206 1419 moveto +350 1275 lineto +stroke +262 1442 moveto +429 1275 lineto +stroke +341 1442 moveto +500 1283 lineto +stroke +420 1442 moveto +527 1335 lineto +stroke +readpath +V016805A2AEE00A8F82A8E86A8B89A888BA868DA828FA00B7A028FA068DA088BA0B89A0E86A0F82E +00DD00A0F02A0D06A0B09A090BA060DA020FA0037A820FA860DA890BA8B09A8D06A8F02AEF00~ +stroke +246 1375 moveto +<536B7920536572766572> +[31 23 24 13 31 26 15 24 26 0] +xshow +readpath +V00C20340A9989A0011A1988~ +0.50196 0.50196 0.50196 setrgbcolor +eofill +readpath +V00DE00FAAEF00B000246A3F00~ +stroke +readpath +V035C054FA9A89A0111A1988~ +0 0 0 setrgbcolor +eofill +readpath +V020F054FE013900~ +stroke +readpath +V01070680AC500A8982A8784A8686A8487A8289A0000A0289A0488A0686A0784A0981E008B00A080 +1A0804A0606A0408A0109A0000A8109A8407A8606A8804A8802AC600~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V01070680AC500A8982A8784A8686A8487A8289A0289A0488A0686A0784A0981E008B00A0801A080 +4A0606A0408A0109A8109A8407A8606A8804A8802AC600~ +stroke +189 1647 moveto +/LuxiSansHSet1 findfont 31 -31 matrix scale makefont setfont +<50726F63657373696E67> +[20 10 18 15 18 15 16 6 17 0] +xshow +readpath +V0299062CE00C300A0054E80C300A00D4~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V02FA0680AE100A00D4E00C300A0054AE200~ +stroke +688 1615 moveto +<44617461> +[22 17 9 0] +xshow +688 1651 moveto +<53756273797374656D> +[20 18 16 16 15 16 9 17 0] +xshow +920 1652 moveto +992 1580 lineto +stroke +987 1664 moveto +1067 1584 lineto +stroke +readpath +V03E60680AB700A8982A8884A8686A8487A8189A009CA0189A0487A0686A0884A0982A6F00A0802A +0804A0606A0407A0109A001CA8109A8407A8606A8804A8802AB800~ +stroke +937 1615 moveto +<45787465726E616C> +[20 16 8 17 10 18 17 0] +xshow +937 1651 moveto +<53797374656D> +[20 16 15 9 17 0] +xshow +readpath +V02010680AC500A8982A8884A8686A8487A8189A0000A0189A0488A0686A0884A0981E008A00A090 +1A0804A0606A0408A0109A0000A8109A8407A8606A8804A8902AC500~ +0.6 0.6 0.6 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V02010680AC500A8982A8884A8686A8487A8189A0189A0488A0686A0884A0981E008A00A0901A080 +4A0606A0408A0109A8109A8407A8606A8804A8902AC500~ +stroke +438 1647 moveto +<5363686564756C6572> +[20 16 17 17 17 17 8 17 0] +xshow +166 1541 moveto +/LuxiSansHSet1 findfont 47 -47 matrix scale makefont setfont +<4C6567656E64> +[25 27 26 26 27 0] +xshow +readpath +V04FB05D9AB290A0121A3191~ +eofill +readpath +V047405D4A5F00A000BADF00A008B~ +eofill +readpath +V04FB0611A9989A0011A1988~ +eofill +readpath +V04710611A7600~ +stroke +readpath +V04FB0680A9487A000DA1486~ +0.50196 0.50196 0.50196 setrgbcolor +eofill +readpath +V04710680A7A00~ +stroke +readpath +V04FB0648A9988A0010A1988~ +0 0 0 setrgbcolor +eofill +readpath +V04710648A1000~ +stroke +readpath +V04920648A1100~ +stroke +readpath +V04B30648A1100~ +stroke +readpath +V04D50648A1000~ +stroke +1303 1498 moveto +/LuxiSansHSet1 findfont 31 -31 matrix scale makefont setfont +<706978656C2064617461> +[17 7 16 16 7 8 18 17 9 0] +xshow +1303 1554 moveto +<6D6574612026206F626A6563742064617461> +[25 17 9 18 8 21 8 17 18 6 17 16 9 8 18 17 8 0] +xshow +1303 1665 moveto +<636F6D6D616E64732026206D65737361676573> +[15 17 26 26 17 17 17 16 9 20 9 26 17 15 16 17 18 17 0] +xshow +1303 1609 moveto +<72657669657765642064617461> +[9 18 15 8 17 22 17 18 8 17 17 10 0] +xshow +readpath +V03E60377E811500A8F82A8D85A8B89A898BA868EA828EA0000A028FA068DA098BA0B89A0D86A0F8 +2E022A00A0F02A0D06A0C09A080BA060DA020FA0000A820EA860EA880BA8C09A8D05A8F02E811500~ +0.90196 0.90196 0.90196 setrgbcolor +eofill +0 0 0 setrgbcolor +readpath +V03E60377E811500A8F82A8D85A8B89A898BA868EA828EA028FA068DA098BA0B89A0D86A0F82E022 +A00A0F02A0D06A0C09A080BA060DA020FA820EA860EA880BA8C09A8D05A8F02E811500~ +stroke +688 849 moveto +/LuxiSansHSet1 findfont 47 -47 matrix scale makefont setfont +<50726F63657373696E67204A6F6273> +[31 15 26 24 26 23 24 10 27 26 13 23 26 26 0] +xshow +readpath +V03E602B5A8714A0E00A8794~ +0.50196 0.50196 0.50196 setrgbcolor +eofill +readpath +V03E60308A0794A8E00A0714~ +eofill +readpath +V03E602C5A0033~ +stroke +showpage +grestore grestore + +%%EndDocument +%%Trailer +cleartomark countdictstack exch sub { end } repeat restore +%%EOF Index: /trunk/doc/design/specs.tex =================================================================== --- /trunk/doc/design/specs.tex (revision 409) +++ /trunk/doc/design/specs.tex (revision 409) @@ -0,0 +1,1770 @@ +%%% $Id: specs.tex,v 1.1 2004-04-09 02:25:41 eugene Exp $ +\documentclass[panstarrs]{panstarrs} + +% basic document variables +\title{Pan-STARRS Image Processing Pipeline} +\subtitle{Software Requirements Specification} +\author{Eugene Magnier, Paul A. Price} +\shorttitle{IPP SRS} +\group{Pan-STARRS Algorithm Group} +\project{Pan-STARRS Image Processing Pipeline} +\organization{Institute for Astronomy} +\version{01.DR} +\docnumber{PSDC-430-005} + +\begin{document} +\maketitle + +% -- Revision History -- +% provide explicit values for the old versions +% use '\theversion' for the current version (set above) +\RevisionsStart +% version Date Description +01 & 2003.01.01 & First draft \\ +\hline +\theversion & 2003.03.10 & Second draft \\ +\RevisionsEnd + +\listoffigures +\pagebreak + +\tableofcontents +\pagebreak +\pagenumbering{arabic} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\section{Scope} + +\subsection{Identification} + +This document establishes the system requirements for the Pan-STARRS +Image Processing Pipeline (IPP). + +\subsection{System Overview} + +\subsection{Document Overview} + +The Pan-STARRS document naming scheme is PSDC-NNN-MMM-VV, where the VV +entry specifies the document version number. Where documents are +identified without the version number, the latest official version in +that series is implied. + +Open Issues and TBDs in this document are marked \tbd{in bold, red +with surrounding square brackets}. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\DocumentsInternalSection +PSCD-430-xxx & PS-1 Design Reference Mission \\ \hline +PSCD-430-004 & Pan-STARRS IPP C Code Conventions \\ \hline +PSCD-430-006 & Pan-STARRS IPP ADD \\ \hline +PSCD-430-007 & Pan-STARRS IPP PSLib SDR \\ \hline +\DocumentsExternalSection +Posix Standard & Open Group Based Specifications Issue 6, IEEE Std 1003.1, 2003 \\ +\DocumentsEnd + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\section{Requirements} %%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\subsection{Required States and Modes} + +The IPP has NN states: active mode, paused mode, interactive mode. + +\begin{itemize} + +\item {\bf active mode} In active mode, the IPP shall accept images + and metadata from OATS and automatically perform the complete set of + image processing tasks, including both calibration and science image + processing. The IPP will respond to requests for data from the + client science pipelines \tbd{and IPP monitoring team}. + +\item {\bf paused mode} In paused mode, the IPP shall refuse data and + metadata from OATS and data requests from the client science + pipelines. + +\item {\bf interactive mode} In interactive mode, the IPP shall + accept data and metadata from OATS, but will not automatically + process the data. The IPP shall respond to user commands to + initiate portions of the data analysis. +\end{itemize} + +\subsection{System Capability Requirements} + +The IPP shall: + +\begin{itemize} + +\item Accept raw images from OATS at a sustained rate of 1 exposure + per 30 seconds. + +\item Accept metadata from OATS at a sustained rate of \tbd{XXX MB / sec}. + +\item Produce high-quality calibration images from the raw calibration + images. The calibration images shall not introduce systematic + uncertainties greater than \tbd{0.2\%}. \tbd{Requirements on the + speed of processing the calibration images.} + +\item Pre-process the science images with the high-quality calibration + images. + +\item Merge multiple pre-processed science images -- from multiple + telescopes or from sequential, dithered exposures -- into single, + cleaned, stacked images. + +\item Subtract a static sky image from the cleaned, stacked images to + produce an image of only the transient events. + +\item Excise the significant transients and outliers from the + pre-processed science images and merge the cleaned images into the + static sky image + +\item Detect objects on the four types of images: pre-processed + images, the merged image, the difference image, and the static sky + image. + +\item Determine astrometry of the detected objects relative to an + astrometric reference to an accuracy of \tbd{30 mas}. + +\item Determine photometry of the detected objects relative to a + photometric reference to an accuracy of \tbd{5 millimag} relative + photometry and \tbd{10 millimag} absolute photometry in photometric + weather. + +\item Produce a high-quality astrometric reference catalog from the + extracted objects on a time-scale of 6 months. The astrometric + reference shall have an absolute accuracy of \tbd{30 mas} and a + local relative accuracy of \tbd{10 mas}. Proper motions of all + nearly stationary objects shall be determined with an accuracy of + \tbd{XXX mas / year}. + +\item Produce a high-quality photometric reference catalog from the + extracted objects on a time-scale of 6 months. The photometric + reference shall have an consistency across the sky of \tbd{5 + millimag} and an absolute calibration to the external system defined + by \tbd{SDSS} of \tbd{10 millimag}. + +\item Publish the static sky images to the Pan-STARRS published static +sky server on a time-scale of \tbd{1 month}. + +\item Publish the detected objects to the Pan-STARRS published object + database on a time-scale of \tbd{1 week}. + +\item Provide access to external Pan-STARRS clients to the detected + objects on time-scales of \tbd{1 minute} after the image is + processed. + +\end{itemize} + +\subsubsection{Software Coding Requirements} + +\paragraph{CSCI Deliverable} + +All final source code generated for the IPP is to be delivered via +CVS, including the test code. CVS revision history shall be included +and made available via CVS. + +\paragraph{Languages} + +Source code shall be in C. All source code shall be compiled with +`gcc' version v2.95 or higher. + +Scripting language shall be in \tbd{Python, version TBD}. + +\paragraph{Interfaces} + +Access to low-level Library functions shall be provided via C APIs +consisting of the function calls and the defined data structures and +other data types. Access to high-level functions shall be provided +via C APIs as well as SWIG interfaces, where specified. Access to +processing jobs shall be available via the UNIX shell. + +\paragraph{Coding Standards} + +The C code shall comply with ANSI Standard C99. Because the delivered +code is required to run on UNIX machines, the delivered code shall be +in compliance with the language-independent UNIX operating system +standard POSIX (Open Group Based Specifications Issue 6, IEEE Std +1003.1, 2003). Source code files shall use the UNIX line-break +convention (line-feed only). C coding style shall adhere to the +standard defined in the document 'Pan-STARRS C-coding standard' +(PSDC-430-004). \tbd{Python coding shall follow the Python standard +defined in the document TBD}. + +\paragraph{Commenting and Documentation} + +Commenting of delivered C and Python code shall follow the C and +Python coding standards and shall provide tags for Doxygen +interpretation of the comments and program structures. + +Documentation for the IPP consists of source code documentation and +user documentation. Source code documentation shall be generated with +Doxygen from the in-line comments and shall be provided as HTML, +Latex, and man pages. User documentation includes the API usage for +the modules and library functions as well as user interface +description for the higher-level architectural systems. User +documentation shall be delivered as PDF documents. + +\paragraph{Version Control} + +Source code version control shall be implemented with CVS. + +\paragraph{Platform architectures and operating systems} + +Makefiles shall be provided with appropriate flags set so that all +code compiles without warnings under 'gcc -Wall' for the following +platform architectures and operating systems: + +\begin{itemize} +\item x86/Linux +\item PPC/OS-X +\end{itemize} + +The requirement of compiling without warnings includes the allowance +that the output may be filtered to exclude known, specified warnings, +such as those caused by lex-generated code. + +Although the code must compile successfully under all three listed +operating systems, unit testing should only be performed for the +x86/Linux combination. + + +\paragraph{Software Configuration} + +\tbd{Makefiles, directory structures, etc} + +\subsubsection{Architectural Components} + +The IPP is organised into several different software elements, listed +as follows: + +\begin{enumerate} +\item Pixel Server +\item Object Database +\item Metadata Database +\item Analysis Pipelines +\item Controller +\item Scheduler +\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. + +\begin{figure} +\begin{center} +\resizebox{8cm}{!}{\includegraphics{pics/overview.ps}} +\caption{ \label{overview} IPP System Overview} +\end{center} +\end{figure} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\paragraph{Pixel Server} + +\begin{itemize} +\item $T_{\rm min}$ is the minimum time between exposures. $T_{\rm min}$ is +assumed to always be $\ge 30s$. +\item All timing measurements are to execution time as measured on a +\tbd{Reference Pan-Starrs Computation Node} and assumed to be not limited +by network bandwidth. +\end{itemize} + +\begin{enumerate} +\item IPP Pixel Data Scheduler +\item IPP Pixel Data Locality Optimizer +\item IPP Pixel Data Database +\item IPP Pixel Data Retrieval Agent +\item IPP Pixel Data Query Library +\item IPP Pixel Data I/O Library +\end{enumerate} + +\subparagraph{IPP Pixel Data Scheduler (IPP-PDS)} + +{\it Inputs} + +\begin{itemize} +\item Accepts an XML document containing the type of operation and image +meta-data if applicable. +\end{itemize} + +The input document is one of the follow classes of message. + +\begin{itemize} +\item {\em new data notification} +\item {\em move data request} +\item {\em copy data request} +\item {\em delete data request} +\end{itemize} + +\tbd{The format of this XML doc is TBD.} +\tbd{The application layer transport protocol is TBD.} + +{\it Outputs} + +Outputs an XML document containing one or more {\em data managements tasks}. +This document is to be passed through all registered filters that match it's +task type. The document is then sent to the IPP Controller. + +The IPP-PDS can fulfill all of it's modes of operations by generating just two +types of {\em data management tasks}. + +\begin{itemize} +\item {\em retrieve data task} +\item {\em delete data task} +\end{itemize} + +Seemingly there should be a third task type {\em move data} but this can be +broken down into a {\em retrieve data} task and a {\em delete data}. This +strategy has the added benefit of adding atomicity to the operation. + +\tbd{The format of this XML doc is TBD.} +\tbd{The application layer transport protocol is TBD.} + +{\it Configuration} + +A configuration file defining at least the address of IPP Controller and the +IPP Pixel Data Database connection string. + +\tbd{The format of this file is TDB.} + +{\it Performance} + +The IPP-PDS must be able to concurrently: + +\begin{itemize} +\item receive and process 260 {\em new data notifications} in less time +then ${T_{\rm min}}$. +\item generate, filter, and transmit 260 {\em data management tasks} in less +time then ${T_{\rm min}}$. +\end{itemize} + +\subparagraph{IPP Pixel Data Locality Optimizer (IPP-PDLO)} + +{\it Inputs} + +\begin{itemize} +\item Accepts an XML document containing one or {\em data management tasks}. +\end{itemize} + +\tbd{The format of this XML doc is TBD.} +\tbd{The I/O protocol is TBD (possibly stdin/stdout).} + +{\it Outputs} + +\begin{itemize} +\item Outputs an XML document containing one or {\em data management tasks}. +\end{itemize} + +\tbd{The format of this XML doc is TBD.} +\tbd{The I/O protocol is TBD (possibly stdin/stdout).} + +\subparagraph{Configuration} + +A configuration file defining what sort of optimization should be done and +the IPP Pixel Data Database connection string. + +\tbd{The format of this file is TDB.} + +\subparagraph{Performance} + +\begin{itemize} +\item The time spent in this filter should be added to the execution timing of +the IPP Pixel Data Scheduler and can not cause it to exceed $T_{\rm min}$. +\end{itemize} + +\subparagraph{IPP Pixel Data Database (IPP-PDD)} + +The IPP Pixel Data Database will maintain a record of {\em new data notifications} +received from the Summit Pixel Server, the storage location of downloaded but +unreduced image data, the storage location of reduced image data, the storage +location of stacked image data, and the storage location of calibration data. +\tbd{In addition to the storage location(s) of image data some or all of it's +associated meta-data will contained in the IPP-PDD} + +{\it Interfaces} + +\begin{itemize} +\item Native database bindings +\item ODBC +\end{itemize} + +{\it Configuration} + +\tbd{Database scheme is TBD.} + +{\it Functionality} + +\begin{itemize} +\item Linux $\ge$ 2.4.x and Glibc $\ge$ 2.3 +\item SQL Syntax $\ge$ SQL-99 +\item native bindings for C and Perl +\item databases size $\ge 1TB$ +\item ODBC $\ge 3.5$ +\item basic stored procedure support +\item hot backups +\item replication +\end{itemize} + +{\it Performance} + +\begin{itemize} +\item Process $> 30 \times 260$ select, insert, update, or delete queries in less time then +${T_{\rm min}}$. +\end{itemize} + +\subparagraph{IPP Pixel Data Retrieval Agent (IPP-PDRA)} + +One instance of the IPP Pixel Data retrieval Agent is spawned per +{\em data management task} that needs to be serviced. The IPP Pixel Data I/O +Library will be used to retrieve a URI into memory and to write data from +memory to a specified URI. \tbd{File lock management may or may not be +necessary within this component.} + +{\it Inputs} + +\begin{itemize} +\item Accepts an XML document containing one or {\em data management tasks}. +\end{itemize} + +\tbd{The format of this XML doc is TBD.} +\tbd{The I/O protocol is TBD (possibly stdin/stdout).} + +{\it Outputs} + +\begin{itemize} +\item Returns an XML document containing one or completed {\em data management tasks}. +\end{itemize} + +\tbd{The format of this XML doc is TBD.} +\tbd{The I/O protocol is TBD (possibly stdin/stdout).} + +{\it Configuration} + +A configuration file defining the address of the IPP Controller. + +\tbd{The format of this file is TDB.} + +{\it Performance} + +\begin{itemize} +\item Must capable of fully saturating a $1Gb/s$ network connection via the +IPP-PDIOL. +\end{itemize} + +\subparagraph{IPP Pixel Data Query Library (IPP-PDQL)} + +The IPP Pixel Data Query Library must hide all SQL details from the caller. + +{\it Interfaces} + +\begin{itemize} +\item C API +\item Perl (XSub of the C API) API +\end{itemize} + +{\it Configuration} + +A configuration file with the database connection string. + +\tbd{The format of this file is TDB.} + +{\it Query Types} + +The IPP-PDQL only supports simple database queries. + +\tbd{The specific queries supported is TDB.} + +{\it Performance} + +\begin{itemize} +\item Process $> 30$ select, insert, update, or delete queries in less time then +${T_{\rm min}}$. +\end{itemize} + +\subparagraph{IPP Pixel Data I/O Library (IPP-PDIOL)} + +The IPP Pixel Data I/O Library retrieves data from or writes data to \cite{uri}s. +Must be able to download multiple segments of a file simultaneously if the +transport protocol supports it. Similar to the \cite{proz} download accelerator. +Must be able to handle file locking issues if the transport protocol supports it. +The HTTP/WEBDAV protocol should be implement with the \cite{neon} library. + +{\it Interfaces} + +\begin{itemize} +\item C API +\item Perl (XSub of the C API) API +\end{itemize} + +{\it Configuration} + +A configuration file defining the optional behaviors for the protocols that +have optional features. + +\tbd{The format of this file is TDB.} + +{\it Protocols} + +Must support at least the following protocols: + +\begin{itemize} +\item \cite{http} +\item \cite{http} w/\cite{webdav} +\item \cite{ftp} +\item \cite{rsync} +\item file +\end{itemize} + +{\it Performance} + +\begin{itemize} +\item Must capable of fully saturating a $1Gb/s$ network connection. +\end{itemize} + +\subparagraph{Pixel Data Flow} + +\subparagraph{Bandwidth} + +\begin{enumerate} +\item Summit Pixel Server(s) +\begin{itemize} +\item $n \times$ \tbd{TBD} +\begin{itemize} +\item $\frac{2 \times 2.4Gb/s}{n}$ +\end{itemize} +\end{itemize} +\item Summit Core Switch +\begin{itemize} +\item Cisco 65xx +\begin{itemize} +\item $2 \times 2.4Gb/s$ +\end{itemize} +\end{itemize} +\item Summit Border Router +\begin{itemize} +\item Cisco 76xx +\begin{itemize} +\item $1 \times 2.4Gb/s$ +\end{itemize} +\end{itemize} +\item Summit $\Longleftrightarrow$ Data Center connection (WAN link) +\begin{itemize} +\item $2 \times 1Gb/s$ Ethernet (over ATM/Sonet) or OC-48 Sonet +\begin{itemize} +\item $1 \times 2.4Gb/s$ +\end{itemize} +\end{itemize} +\item Data Center Border Router +\begin{itemize} +\item Cisco 76xx +\begin{itemize} +\item $1 \times 2.4Gb/s$ +\end{itemize} +\end{itemize} +\item IPP Cluster Core Switch +\begin{itemize} +\item Cisco 65xx +\begin{itemize} +\item $48Gb/s$ +\end{itemize} +\end{itemize} +\item IPP Cluster Nodes +\begin{itemize} +\item $240 \times$ \tbd{Reference Pan-Starrs Computation Node} +\begin{itemize} +\item $\frac{48Gb/s}{240}$ +\end{itemize} +\end{itemize} +\item Extended Network +\begin{itemize} +\item Cisco 65xx +\begin{itemize} +\item \tbd{TBD} +\end{itemize} +\end{itemize} +\item Static Sky DB, other components, etc. +\begin{itemize} +\item \tbd{TBD} +\begin{itemize} +\item \tbd{TBD} +\end{itemize} +\end{itemize} +\end{enumerate} + +\begin{figure} +\begin{center} +% \resizebox{!}{20cm}{\includegraphics{pixel_wan.epsi}} +\caption{ \label{acquisition} Pixel Data Flow: Bandwidth} +\end{center} +\end{figure} +\pagebreak + +\subparagraph{Bandwidth Estimates} + +{\it Assumptions} + +\begin{itemize} +\item $T_{\rm min} = 30s$ +\end{itemize} + +{\it Exposure with overclocks in integer} + +{\it Storage Size} +$$2bytes \times (4096^2pixels \times 1.125overclocks) \times 240otas = 72477573120b$$ + +{\it Bandwidth Requirement} +$$\frac{72477573120b}{T_{\rm min}} = 2415919104b/s$$ + +{\it Exposure in float} + +{\it Storage Size} +$$4bytes \times 4096^2pixels \times 240otas = 128849018880b$$ + +{\it Bandwidth Requirement} +$$\frac{128849018880b}{T_{\rm min}} = 4294967296b/s$$ + +{\it Stacked exposure in float} + +{\it Storage Size} +$$4bytes \times 4096^2pixels \times 60otas = 32212254720b$$ + +{\it Bandwidth Requirement} +$$\frac{32212254720b}{T_{\rm min}} = 1073741824b/s$$ + +{\it Full calibration set in float} + +$$(1 \times debias, 1 \times dark, 1 \times flat, 2 \times fringe, 2 \times sky)$$ + +{\it Storage Size} +$$7 \times (exposure\ in\ float) = 901943132160b$$ + +{\it Bandwidth Requirement} +$$\frac{901943132160b}{T_{\rm min}} = 30064771072b/s$$ + +{\it Aggregate Bandwidth Requirement} + +\begin{center} +% \begin{tabular}{>{$}l<{$}>{$}r<{$}l} +\begin{tabular}{lrl} +[phase 2]&&\\ + & 2415919104b/s & summit $\rightarrow$ disk (exposure)\\ ++& 2415919104b/s & non-local disk $\rightarrow$ memory (exposure)\\ ++& 30064771072b/s& non-local disk $\rightarrow$ memory (calibration)\\ ++& 4294967296b/s & memory $\rightarrow$ non-local disk (reduced)\\ +\cline{1-2} + & 39,191,576,576b/s &\\ + +[phase 4]&&\\ + & 4294967296b/s & non-local disk $\rightarrow$ memory (reduced)\\ ++& 1073741824b/s & non-local disk $\rightarrow$ memory (best)\\ ++& 1073741824b/s & non-local disk $\rightarrow$ memory (working)\\ ++& 1073741824b/s & memory $\rightarrow$ non-local disk (diff)\\ ++& 1073741824b/s & memory $\rightarrow$ non-local disk (working)\\ +\cline{1-2} + & 8,589,934,592b/s &\\ + +[total]&&\\ + & 39191576576b/s & [phase 2] total\\ ++& 8589934592b/s & [phase 4] total\\ +\cline{1-2} + & 47,781,511,168b/s & $\sim48Gb/s$ +\end{tabular} +\end{center} + +\subparagraph{IPP Pixel Data Database Query Estimates} + +{\it Assumptions} + +\begin{itemize} +\item There is no caching of query results. +\end{itemize} + +{\it Acquisition} + +\begin{itemize} +\item select new data notification from IPP Data Scheduler +\item insert new data notification from IPP Data Scheduler +\item select from IPP Pixel Data Locality Optimizer +\item select new data notification from IPP Pixel Data Scheduler +\item update new data notification from IPP Pixel Data Scheduler +\item select data available from IPP Pixel Data Scheduler +\item insert data available from IPP Pixel Data Scheduler +\end{itemize} + +{\it Phase 2} + +\begin{itemize} +\item select data available from IPP Scheduler +\item select $\times 7$ calibration data from IPP Image Agent +\item select data available from IPP Scheduler +\item update data available from IPP Scheduler +\item select reduced data available from IPP Scheduler +\item insert reduced data available from IPP Scheduler +\end{itemize} + +{\it yPhase 4} + +\begin{itemize} +\item select reduced data available from IPP Scheduler +\item select $\times 2$ stacked data from IPP Image Agent +\item select reduced data available from IPP Scheduler +\item update reduced data available from IPP Scheduler +\item select stacked data available from IPP Scheduler +\item insert stacked data available from IPP Scheduler +\item select difference data available from IPP Scheduler +\item insert difference data available from IPP Scheduler +\end{itemize} + +\begin{verbatim} +\bibitem[Link aggregation]{aggregation} +http://cisco.com/en/US/products/hw/switches/ps708/products\_configuration\_guide\_chapter09186a008019f011.html +\bibitem[ProZilla]{proz} +http://prozilla.genesys.ro/ +\bibitem[neon]{neon} +http://www.webdav.org/neon/ +\bibitem[Uniform Resource Identifiers (URI)]{uri} +ftp://ftp.rfc-editor.org/in-notes/rfc2396.txt +\bibitem[HTTP]{http} +ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt +\bibitem[WEBDAV]{webdav} +ftp://ftp.rfc-editor.org/in-notes/rfc2518.txt\\ +ftp://ftp.rfc-editor.org/in-notes/rfc3253.txt\\ +ftp://ftp.rfc-editor.org/in-notes/rfc3648.txt +\bibitem[FTP]{ftp} +ftp://ftp.rfc-editor.org/in-notes/rfc454.txt +\bibitem[rsync]{rsync} +http://rsync.samba.org/ +\end{verbatim} + +\subsubsection{Analysis Stages} + +We now consider the collection of analysis tasks which are performed +by the IPP. Depending on the task, they may be performed on +individual images, collections of images, or on derived data products. +Because of the nature of the image data, many of the analysis tasks +can be performed in parallel because, for example, the analysis of an +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: + +\begin{enumerate} + \item Science Image Pipelines + \begin{enumerate} + \item Phase 1 : image processing preparation + \item Phase 2 : image reduction + \item Phase 3 : exposure analysis + \item Phase 4 : image combination + \end{enumerate} + \item Calibration Image Pipelines + \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 + \end{enumerate} + \item Reference Catalog Pipelines + \begin{enumerate} + \item Astrometry reference catalog generation + \item Photometry reference catalog generation + \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 +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. + +\begin{figure} +\begin{center} +\resizebox{8cm}{!}{\includegraphics{pics/pipelines.ps}} +\caption{ \label{pipelines} IPP System Overview} +\end{center} +\end{figure} + +\paragraph{Phase 2 Concept} + +Phase~2 processing within the Pan-STARRS image processing pipeline is +the de-trend stage, where the images from the detector are processed +to remove instrumental signatures. The following operations need to +occur within Phase~2 processing: +\begin{enumerate} +\item Convolve de-trend images with the OT kernel; +\item Flag bad and saturated pixels; +\item Bias correction via overscan subtraction; +\item Trim object image to remove overscan and edges corrupted by OT; +\item Correct for non-linearity; +\item Flat-field correction; +\item Sky subtraction; +\item Identify CRs; +\item Find objects in the image; and +\item Make postage stamps of bright objects. +\end{enumerate} +These operations are each explained below. + +\paragraph{Convolve de-trend images with the OT kernel} + +De-trend images must be convolved by the OT kernel, so that +they accurately represent the de-trend images appropriate for +the object images, which have been shifted using OT. + +\paragraph{Flag bad and saturated pixels} + +A static bad pixel mask needs to be used to identify pixels which are +bad. Note that bad pixels which are charge traps need to be grown by +the extent of the OT convolution kernel, while those pixels above a +charge trap (i.e.\ bad colums) should not be grown, since they were +not affected by pixel shifting, but only became bad at read-out. + +Pixels saturated in the A/D converter should also be masked, and this +area should be grown by an additional pixel to mask excess charge +spillover. + +\paragraph{Bias correction via overscan subtraction} + +The overscan must be averaged (either in bulk, or individually by +rows) or fit with a polynomial, and the result subtracted from the +image. Overscan rows with a standard deviation which exceeds a +given threshold should be masked. + +\paragraph{Trim object image} + +The overscan must be trimmed from the object image, along with +those pixels near the edges that have been compromised due to OT +operation. + +\paragraph{Correct for non-linearity} + +The object image (after bias correction) must be corrected for the +effects of non-linearity through a polynomial fit. + +\paragraph{Flat-field correction} + +The object image (after bias correction and non-linearity correction) +must be corrected for sensitivity differences as a function of position, +through dividing by a flat field image. + + +\paragraph{Sky subtraction} + +The flux contribution of the sky (both continuum emission and the line +emission that causes fringing) must be subtracted from the +flat-fielded object image. + +\paragraph{Identify CRs} + +CRs should be identified, if possible on the basis of their morphology +in the flat-fielded object image (from a single focal plane), and +masked. The mask must be grown by an additional pixel. + +\paragraph{Find objects in the image} + +Objects on the flat-fielded object image must be found, and general +parameters, including the centre, magnitude and shape measured. + +\paragraph{Postage Stamps} + +Objects on the flat-fielded object image falling within a specified +magnitude range should have subimages saved for the purpose of more +accurate photometry and astrometry. + + +\paragraph{Phase 4 Concept} + +Phase 4 processing within the Pan-STARRS image processing pipeline is +the final stage of processing. 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. + +Here we give the specifications for the implementation of Phase 4 +processing. + + +\paragraph{Functionality} + +Phase 4 must consist of the following elements: +\begin{enumerate} +\item Combine images --- the images from each telescope are to be +combined in order to obtain a deep image free from artifacts (e.g.\ +cosmic rays, low-altitude streaks); +\item Identify variable sources --- the combined image is to be +compared with the static sky image and variable sources identified; and +\item Add to static sky --- the combined image is to be added to the +static sky so that an incrementally-deeper static sky image may be +made. +\end{enumerate} + +\subparagraph{Products} + +Phase 4 must produce the following data products at a minimum: +\begin{enumerate} +\item Subtracted image --- the combined image using each of the +telescopes, with the static sky subtracted; +\item New static sky image --- the combined image using each of the +telescopes, with the (old) static sky added; +\item Metadata about the quality of each of these images; and +\item A catalogue of variable sources. +\end{enumerate} + + +\paragraph{Performance} + +\subparagraph{Timing} + +It is required that the {\em total} processing for each exposure by +the Pan-STARRS system not take longer than $n \times T_{\rm min}$, +where $T_{\rm min}$ is the minimum time between exposures (30 sec), +and $n$ is a small positive number. Increasing $n$ results in a +proportionally higher expenditure on CPUs, hence it is strongly +desirable that $n \le 2$. + +Since we envision 4 OTAs (each 4k pixels, square) being processed by a +single CPU, we need Phase 4 to process 64 (input) Mpix in +approximately 30 sec (since Phase 4 is the most intensive, it should +receive the lion's share of the time budget), or 2 (input) Mpix per +second. + +\subparagraph{Accuracies} + +Transformations/mappings from detector to sky must preserve both +photometric and astrometric accuracies: +\begin{itemize} +\item Relative photometric accuracy better than 0.005 mag {\bf [???]}. +\item Absolute photometric accuracy better than 0.02 mag {\bf [???]}. +\item Relative astrometric accuracy better than 0.02 arcsec {\bf [???]}. +\item Absolute astrometric accuracy better than 0.2 arcsec {\bf [???]}. +\end{itemize} + + +\subparagraph{Robustness} + +It is essential that the static sky image (which may have been +painstakingly accumulated over many months) not be corrupted by adding +in transient sources, or data that is of suspect quality (due, e.g., +to an error upstream in the processing). + + +\subsubsection{Modules} + +\subsubsection{PanSTARRS IPP 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, \code{PSLib}. + +The Pan-STARRS Data 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. The library is organized into +four topics: System Utilities, Basic Data Collections, Data +Manipulation, and Astronomy-Specific Functions. + +The required functionality of the Pan-STARRS Data Library is specified +by the document `Pan-STARRS Image Processing Pipeline Library, +Supplementary Design Requirements' (PSDC-430-007), and details of +specified algorithms are specified in the document `Pan-STARRS Image +Processing Pipeline Algorithm Design Document' (the ADD; +PSDC-430-006). + +\subsubsection{Data Sources and Formats} + +\paragraph{Image Formats} + +FITS images + +\paragraph{Table Formats} + +FITS tables + +\paragraph{Other Data Formats} + +XML files + +\paragraph{External Catalogs} + +\begin{itemize} +\item USNO-A +\item USNO-B +\item HST-GSC +\item Tycho +\item 2Mass +\end{itemize} + +\paragraph{Analysis Reference Data} + +\begin{itemize} +\item Telescopes +\item Cameras +\item Detectors +\item Filters +\item software basic parameters +\end{itemize} + +\paragraph{Installation Reference Data} + +\begin{itemize} +\item computers +\end{itemize} + +\subsection{External Interfaces} + +\subsection{Internal Interfaces} + +\subsection{Internal Data Requirements} + +\subsection{Computer Hardware} + +\subsubsection{Overview} + +This document discusses the likely range of the Pan-STARRS Image +Processing Pipeline (IPP) hardware requirements. The hardware +requirements addressed in this document consist of: + +\begin{itemize} +\item Total Disk Volume +\item Total Processing Power +\item Sustained Switch Bandwidth +\item Sustained Node Network I/O +\item Sustained Disk I/O +\end{itemize} + +Even without the complete IPP design, it is possible to identify the +major drivers on the hardware requirements. The total disk volume +requirements are dominated by the need to store raw images for a +certain period, the need to store calibration images for a longer +period, and the need to store the static sky images. Of the various +analysis pipelines, and depending on the data organization as +discussed below, Phase 2 and Phase 4 present the most significant +demands in terms of data I/O throughput on the network. Phase 2 and +Phase 4 also present the most significant CPU demands. In this +discusion, Phase 2 refers to the per-OTA image pre-processing in which +the instrumental signature is removed and a first pass object +detection is performed. Phase 4 refers to the multiple OTA +combination in which the pre-processed images are merged and combined, +in both addition and subtraction, with the static sky image, and up to +three object detection passes are performed. + +This document does not address the hardware requirements implied by +the Phase 0, 1, or 3 stages, nor the load required by the calibration +image creation stages. In the first instance, the operations are only +performed on the metadata and are extremely minimal both in terms of +data I/O and computation requirements. In the second case, the +processing is less time critical than the per-image processing and is +performed only infrequently (once per night to once per week or +month). This document also does not address any hardware requirements +introduced by the metadata manipulation. The software implementation +for metadata storage (RDBMS, FITS tables, etc) will have a very large +impact and will be evaluated along with the needed hardware at a later +date. + +\subsubsection{Scenarios} + +We will address the various hardware requirements by referring to a +set of data processing and data organization scenarios. The actual +hardware requirements will depend on design decisions which are not +yet available. It is possible to define the data organization in ways +which will minimize the hardware requirements, but which will increase +the software development effort. We will discuss both the worst-case +data organization scenario, which does not require significant +intelligence in the software systems, and the optimal data +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 +based on the Design Reference Mission [REF]. + +The IPP hardware system must provide both data storage and +computational resources. The IPP requires relativley 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. The first +assumption we make is that the hardware is organized into nodes which +provide both data storage and computational resources. The second +assumption we make is that the data storage nodes are divided into two +classes: those which deal with the per-OTA data and those that provide +the static sky storage. In addition, we assume that 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 used in this configuration; although it is +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 +system. In such a case, the interswitch communication must also meet +the required throughput needs. We discuss the hardware requirements +in the assumption that such an organization will be necessary. + +The way in which the images are distributed among the storage and +compute nodes will largely determine the I/O bandwidth requirements. +For data bandwidth requirements calculations, it is necessary to make +some assumptions about the data organization. For the purposes of +this document, we explore two extreme-case options: +\begin{itemize} +\item Random Data Distribution - OTA \& Sky data is randomly + distributed within the compute node of a given type (ie, OTA data is + randomly distributed among the OTA compute nodes). +\item Optimal Data Distribution - OTA \& Sky data is optimally + distributed to compute OTA/Sky nodes (OTA processing is always on a + machine with local OTA data). +\end{itemize} +A second factor which will have a significant impact on the I/O +requirements is the image storage format for the processed and +calibration images. We have two basic choices: 32 bit floating point +format or 16 bit integer format with appropriate scaling. In the +former case, additional dynamic range is retained, while in the latter +case, we reduce the data volume by a factor of 2. While some may +argue that the higher dynamic range is necessary, arguments can be +made that the 16 bit range is sufficient. (In particular, the 16 bit +data provides a dynamic range far above the expected 1/1000 fractional +accuracy of the flat-field images). A related question is the number +of calibration images needed by the processing system. Since the +complete analysis is not yet defined, this number is difficult to +ascertain. However, we can make a range of assumptions which are +reasonable. We therefore adopt two data volume scenarios to explore +these possibilites: +\begin{itemize} +\item Standard Data Volume - 32 bit data for processed and calibration + images, average of 7 calibration frames per image. +\item Minimal Data Volume - 16 bit data for processed and calibration + images, average of 4 calibration frames per image. +\end{itemize} +In the discussion that follows, we explore the hardware requirements +implied by the collection of four combinations of these two sets of +scenario options. + +\begin{table} +\begin{center} +\caption{Hardware Throughput Tests \label{existing-hardware}} +\begin{tabular}{lrrrr} +\hline +\hline +Test & where \& when & model & result \\ +\hline +node I/O & CFHT 11/2002 & Intel 1000 Gigabit & 35 - 40 MB/s sustained \\ +node I/O & CFHT 2/2004 & Intel 1000 Gigabit & 65 - 70 MB/s sustained \\ +RAID write & CFHT 2/2004 & 3ware RAID cntl + IDE & 110 MB/s sustained \\ +Switch Load & VeriTest & Cisco & 3 GB/s (for 32 ports) \\ +\hline +\end{tabular} +\end{center} +\end{table} + +\subsubsection{Existing Hardware Throughput} + +We have collected a few representative tests of various pieces of +modern hardware to give a reference for the throughput capabilities. +A number of hardware configurations have been tested at CFHT for the +Elixir project, and we include here their recent reported hardware +RAID-5 I/O speeds and GigE card speeds. We also have included data +from VeriTest studies of Cisco switch throughput, commissioned by +Cisco for a 32 port GigE switch. These tests are summarized in +Table~\ref{existing-hardware}. + +\begin{table}[b] +\begin{center} +\caption{Data Storage Requirements \label{storage}} +\begin{tabular}{lrrrr} +\hline +\hline + & Standard / PS-4 + & Standard / PS-1 + & Minimal / PS-4 + & Minimal / PS-1 \\ +\hline +Raw data & 300 TB & 75 TB & 300 TB & 75 TB \\ +static sky & 512 TB & 64 TB & 256 TB & 32 TB \\ +calibration frames & 175 TB & 18 TB & 17 TB & 5 TB \\ +metadata db & 2 TB & 2 TB & 0.2 TB & 0.2 TB \\ +object db & 60 TB & 4 TB & 60 TB & 4 TB \\ +\hline +totals & 1050 TB & 163 TB & 633 TB & 116 TB \\ +\hline +\end{tabular} +\end{center} +\end{table} + +\subsubsection{Data Storage Requirements} + +The Pan-STARRS 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. +We discuss each of these data items and their impact on the data +storage requirements for the IPP, and identify the impact of the +minimal vs standard data storage requirements as well as the +requirements specifically for PS-1. Table~\ref{storage} summarizes +the data storage requirements in the different scenarios. + +\paragraph{Raw Data Storage} + +There are two basic image types which will be acquired: night-time +science images and calibration images. The night-time science images +consist of 1Gpix per image, or 2GB in raw format. At nominal cadence, +the 4 telescopes can obtain images at a sustained rate of 1 image per +30 seconds per telescope for the entire night of 10 hours (36000 +minutes). A total of 100 calibration images per night would be a +substantial overestimate of the typical expectation. Combining these +numbers, we can expect to receive a total of 1300 image per telescope +per night, 5200 image total, or 10.4 TB of data per night. The total +data storage requirements for the raw data are governed by the number +of nights' worth of data we are required to keep online. A reasonable +number is one month to allow a full moon's cycle. Thus, for raw image +storage, we require a total of 300 TB data storage. For PS-1, this +number is simply scaled down by a factor of 4. The choice of the +minimal data volume does not affect these numbers because the raw data +is already stored with 16 bit pixels. ({\bf note: the PS-1 design +reference may now require storage of the entire first year of data, +calculated to be 200 TB}). + +\paragraph{Static Sky Data Storage} + +The static sky is represented by images with 0.2 arcsec per pixel. +There will be one summed image and one weight image for each of the 6 +filters, each stored in floating point format. At this resolution, +there are 324 Mpix per square degree, and we will observe a potential +total area of 30,000 square degrees. Allowing for 10\% overage for +overlapping tiling, we require a total of 10.7 Gpix to cover the sky +once, or a total of $\sim 512$ TB for the static sky images. In the +minimal data volume scenario, this value is reduced by a factor of 2, +while in PS-1, the reduction is a factor of roughly 8 because we only +intend to store the static sky for the ecliptic plane survey and the +small IPP verification program ({\bf note: this last point is no +longer valid - the PS-1 static sky may require the entire 3pi}). + +\paragraph{Calibration Frame Storage} + +The possible required calibration frames consist of the bias, dark, +and mask images, along with one flat, one flat-correction, and +multiple sky/fringe library frames per filter. In fact, not all types +are needed at all stages. For the standard data volume, we assume an +average of 7 calibration frames per image and filter. This results in +a total of 42 master calibration image per telescope. If we intend to +keep all master calibration frames for the project lifetime, and +generate a new master on a weekly basis (a reasonable time-scale), +then we can expect to require a total of 175 TB of calibration image +by the end of the 5 year lifetime of the project. For the case of +PS-1, the time period is only 2 years, and there is only 1 telescope, +resulting in a factor of 10 reduction in the volume. For the minimal +data case, we reduce the volume by another factor of 3.5. We also note +that this is likely to be a drastic overestimate as we are unlikely to +need to regenerate all master calibration frames on a weekly +time-scale. + +\paragraph{Metadata Database Storage} + +The metadata data storage requirements are driven by the need to store +the data for the project lifetime. There are two types of metadata +generated at the summit: data associated with images and environmental +data. The environmental data consists of measurements on a regular +cadence, roughly 1 per minute, of a variety of parameters. We suggest +an expected of 1kB per entry, for a total of 2.6 GB over the lifetime +of the project. PS-1 will represent a smaller amount of data per +minute, and also a factor of 2.5 fewer minutes. We suggest PS-1 may +have a total environmental metadata set smaller by a factor of 5. The +additional systems, such as the DIMM, SkyProbe, NIR Sky Camera, and +the LRProbe will have higher data requirements, but should be +considered as separate, self-contained systems. Their data products +are distilled to a limited number of parameters per minute which are +included in the 1kB given above. Furthermore, items such as +guide-star history, if saved, will be saved with the image data and +represents only a small fraction of the total image data volume. Some +subset of the telescope diagnosic information may be a high volume +data product as well, but only retained by the telescope control +system for the purpose of diagnostic studies. Such data will be +excluded from this analysis. + +The image metadata consists of values associated with the FPA (4), the +OTAs (240), and the Cells (15360). Aside from the guide star history, +the total data requirements for each of these entries will be scaled +by the number of bytes required for the metadata from each data level. +Clearly, if the Cell entry is allowed to be large, it will dominate +the total Metadata data volume. If we suggest an expected number of +64 bytes per Cell, 256 B per OTA, and 1k per FPA, we find a total +metadata volume per exposure of roughly 1 MB, completely dominated by +the Cell metadata. With the exposure rates above, we find a total of +metadata volume of 1.8 TB over the lifetime of the project. For PS-1, +the total volume is reduced by a factor of 2.5 (for the shorter +lifetime) and another factor of 4 (for the lone telescope). Neither +data quantity is affected by the minimal vs standard data volume +choice. + +\paragraph{Object Database Storage} + +The hardware requirements for the IPP object database are rather +flexible: the total volume depends critically on the depth to which +the object detection analyses are performed (and thus the total number +of object detections) and the number of object parameters which are +measured. We can make very rough estimates that the total number of +detections over the 5 year lifetime of the project may be in the +vicinity of $5\times10^{11}$. We can conservatively estimate the +number of bytes needed to represent each detection as 128 B, resulting +in a total data storage for the object detections of 60 TB. However, +this number depends strongly on the timescale for which the IPP is +required to maintain all object detections, and may potentially be +significantly reduced. For the case of PS-1, the total number of +detections is likely to be reduced by a factor of 4 for the number of +telescopes, and potentially another significant factor ($\sim 4?$) by +limiting the depth of object detections. Again, the minimal data +volume scenario is irrelevant to the object database volume. + +\subsubsection{CPU Requirements} + +Phase 2 and Phase 4 dominate the processing requirement, primarily +because they must keep up with the image delivery rate of 1 per 30 +seconds. We have performed benchmarks of a demonstration version for +both the Phase 2 and Phase 4 analyses. + +For the Phase 2, a substantial fraction of the processing time is +consumed by the need to perform FFTs on the images in order to +convolve them with the guide-star kernel, and in the smoothing used +for the object detection process. Additional processing time is +needed by the object detection, deblending, and analysis. Experiments +with the FFTW package show that FFTs may be performed on Intel +processors at rates of approximately 0.25 GHz-sec / Mpix for data sets +of order 1 Megapixel. The FFTs required for the Phase 2 analysis are +performed on the 512$^2$ pixel cells, so these numbers may roughly be +scaled linearly to determine the total time required for OTA +processing. A single FFT on a full OTA, with 64 Cells, therefore +requires roughly 4 GHz-sec. For the full Phase 2 analysis, there are +roughly 4 single direction FFTs required excluding those associated +with object detection; thus the total processing time for these FFTs +is approximately 16 GHz-sec. The addtional analysis steps, excluding +object detection and characterization, account for a small fraction of +this compute time, which we estimate at 10\%. The object detection +stage depends somewhat on the depth to which the analysis is +performed, and the number of measurements made per object. Typical +analysis performed by the Sextractor routine, which performs a +substantial number of per-object analyses, requires 27 GHz-sec for a +full OTA, including the FFTs used for smoothing. We can therefore +assume a total of 50 GHz-sec per OTA for the Phase 2 processing. This +converts to a total of 12000 GHz-sec for a complete major frame. + +For Phase 4, the main computational tasks are combining the multiple +images, with cosmic-ray rejection, and performing the object detection +tasks. Nick Kaiser has done tests of the Phase 4 image combine and +rejection stages, and finds a total processing time of roughly 96 +GHz-sec for a full stack of 4 OTA images. If we add in an additional +34 GHz-sec for detailed object detection and image differencing, we +find a conservative estimage of 130 GHz-sec for a 4-image OTA stack, +equivalent to 7800 GHz-sec for a major frame. + +For PS-1, the data processing will clearly require a smaller amount of +computational resources because of the lower image rate. However, the +total number of GHz-sec required for the complete analysis of 4 input +images and the combination with the static sky will remain +more-or-less the same. Some reduction in the load may be gained by +reducing the complexity and depth of analysis for PS-1. Depending on +the details and depth of the analysis, we may reduce the computational +load by a factor of 2. + +\begin{table} +\begin{center} +\caption{Data Scenarios (MB per OTA or Sky-cell) \label{scenarios}} +\begin{tabular}{lrrrr} +\hline +\hline + & Random / Standard & Random / Minimal & Optimal / Standard & Optimal / Minimal \\ +\hline +{\em Phase 2 input} & & & & \\ +from summit & $2 \times 32$ MB & $2 \times 32$ MB & $2 \times 32$ MB & $2 \times 32$ MB \\ +input image & 32 MB & 32 MB & {\bf 32 MB} & {\bf 32 MB} \\ +calibration & $7 \times 64$ MB & $4 \times 32$ MB & {\bf 7 $\times$ 64 MB} & {\bf 4 $\times$ 32 MB} \\ +mask image & 16 MB & 8 MB & {\bf 16 MB} & {\bf 8 MB} \\ +\hline +network I/O: & 560 MB & 232 MB & 64 MB & 64 MB \\ +disk I/O: & (560 MB) & (232 MB) & 496 MB & 168 MB \\ + & & & & \\ +{\em Phase 2 output} & & & & \\ +output image & 64 MB & 32 MB & {\bf 64 MB} & {\bf 32 MB} \\ +output mask & 16 MB & 8 MB & {\bf 16 MB} & {\bf 8 MB} \\ +image to P4 & $1.5 \times 4 \times 64$ MB & $1.5 \times 4 \times 32$ MB & $1.5 \times 4 \times 64$ MB & $1.5 \times 4 \times 32$ MB \\ +mask to P4 & $1.5 \times 4 \times 16$ MB & $1.5 \times 4 \times 8$ MB & $1.5 \times 4 \times 16$ MB & $1.5 \times 4 \times 8$ MB \\ +\hline +network I/O: & 200 MB & 100 MB & 120 MB & 60 MB \\ +disk I/O: & (80 MB) & (40 MB) & 80 MB & 40 MB \\ + & & & & \\ +{\em Phase 4} & & & & \\ +input images & $1.5 \times 4 \times 64$ MB & $1.5 \times 4 \times 32$ MB & & \\ +input masks & $1.5 \times 4 \times 16$ MB & $1.5 \times 4 \times 8$ MB & & \\ +static sky & 64 MB & 64 MB & & \\ +static weight & 64 MB & 32 MB & & \\ +\hline +input: & 608 MB & 336 MB & & \\ +output: & 192 MB & 128 MB & & \\ +\hline +\multicolumn{5}{l}{\em Bold-faced entries are access to local-disk} \\ +\multicolumn{5}{l}{\em parenthesised disk I/O numbers are parallel with the network I/O} \\ +\end{tabular} +\end{center} +\end{table} + +\subsubsection{Per-Node I/O Requirements} + +Data I/O per node is defined as the number of bytes per second passed +through the node's network adapter. The data throughput for each node +depends strongly on the scenarios identified above. In this section, +we identify the data which is passed between nodes for each of the +different scenarios. Table~\ref{scenarios} lists the per-node data +I/O for the four scenarios. + +For PS-4, there are only 30 seconds of compute time allowed for each +of the Phase 2 and Phase 4 analyses. We use the data I/O volumes and +some assumptions about expected network and disk bandwidth to estimate +the I/O and processing timeline for the four scenarios. From this +analysis, we can judge the total CPU requirements in terms of GHz, not +just GHz-sec. We have assumed that GigE network adapters are capable +of delivering data at 50MB/sec sustained and that a disk RAID can +deliver sustained 100 MB/sec reads and writes. These numbers are +conservative estimates based on recent tests discussed above. Using +these assumptions, Table~\ref{throughput} lists the time allocations +for the complete set of scenarios for the case of PS-4. + +\paragraph{Random / Standard Data Scenario} + +In the Random Data Distribution scenario, there is a single CPU +allocated to each OTA in the OTA farm and a single CPU for each Sky +cell process. The OTA data are stored across random machines in the +OTA farm, with the result that every Phase 2 processing requires +network access to the data. For each science OTA image which is +observed, each OTA node will read from the network a total of 560 MB +(the 2 raw images for data storage and the 7 calibration frames, along +with one mask and one raw input image) and write a total of 200 MB +(one processed image and the mask along with the 1.5 processed images +and masks for the Phase 4 analysis). Given the assumption of 50 MB/s +from the network adapter, the total data volume implies an I/O period +of 15.2 seconds. Note that the disk I/O is parallel with the network +I/O and substantially underfills the disk bandwidth. + +\paragraph{Random / Minimal Data Scenario} + +In the Random-Minimal, there is a single CPU allocated to each OTA in +the OTA farm and a single CPU for each Sky cell process, and the OTA +data are stored across random machines in the OTA farm. However, the +calibration and the processed science images are stored at 2 bytes per +pixel, the mask is set at 4 bits per pixel, and only 4 calibration +images are assumed. For each science OTA image which is observed, +each OTA node will read from the network a total of 232 MB (the 2 raw +images for data storage and the 4 calibration frames, along with one +mask and one raw input image) and write a total of 100 MB (one +processed image and the mask along with the 1.5 processed images for +the Phase 4 analysis). Given the assumption of 50 MB/s from the +network adapter, the total data volume implies an I/O period of 6.6 +seconds. Again, note that the disk I/O is parallel with the network +I/O and substantially underfills the disk bandwidth. + +\paragraph{Optimal / Standard Data Scenario} + +In the Optimal Data Distribution scenario, there is a single CPU +allocated to each OTA in the OTA farm and a single CPU for each Sky +cell process. In addition, all data for the specified OTA are stored +on local disks attached to the same computer as the CPU, with the +result that all Phase 2 I/O is made to a local disk. For each science +OTA image which is observed, each OTA node will read from the network +a total of 2 raw images (one for the original image, one for the +backup copy) and write an average of roughly 1.5 processed images and +masks to the Phase 4 machines for a total of 184 MB of network I/O. +During the processing stage, the OTA node will read from disk a total +of 496 MB (7 calibration frames at 64 MB each, one 16 MB mask, and one +raw science image at 32 MB) and write a total of 80 MB (one processed +image at 64 MB and one mask at 8 MB). Given the assumptions for the +network and disk bandwidths (50 MB/s and 100 MB/s respectively), the +data volumes imply a total I/O period of 9.5 seconds. In this +instance, the network I/O is presumed to be sequential with the disk +I/O. + +\paragraph{Optimal / Minimal Data Scenario} + +In the Optimal / Minimal Scenario, the minimal data sizes are used +with the optimal data distribution scheme. In this case, we reduce +the disk I/O volume to 168 read and 40 MB write, and the network +traffic to 124 MB. Given the assumptions for the network and disk +bandwidths, the data volumes imply a total I/O period of 4.6 seconds. +Again, the network I/O is presumed to be sequential with the disk I/O. + +\paragraph{Phase 4 Node I/O Requirements / Standard Data Volume} + +Although it is easy to arrange the OTA data in such a way that the +majority of I/O is performed locally, it is not as easy to arrange +this for the Static Sky data used by the Phase 4 analysis. We +therefore make the assumption that the Phase 4 analysis will require +all input OTA data to be loaded across the network, as well as all +Static Sky data. This is somewhat of an overestimate as some of the +Static Sky data will be processed by machines with the data stored +locally, and clever Static-Sky data organization schemes can enhance +this chance. + +In the Phase 4 analysis, the images from the 4 separate telescopes are +combined into a single image, confronted with the appropriate segment +of the static sky, with output difference image and updated static sky +image. If we restrict input access to the individual OTA cells, the +maximum read overhead is 50\% (need to read a 10x10 set of cells for +an 8x8 input image). If the processing is performed on Static Sky +segments equivalent in size to the OTAs, the input data is 608 MB (384 +MB of processed science image, 96 MB of mask images, 64 MB of static +sky image and 64 MB of static sky weight map) while the output data is +192 MB (static sky, weight map, and difference image, each 64 MB). +Thus, we require a total of 800 MB network I/O. Given the network +bandwidth, this implies an I/O period of 16 seconds for Phase 4. + +\paragraph{Phase 4 Node I/O Requirements / Minimal Data Volume} + +In the minimal data volume scenario, the Phase 4 analysis volume is +significantly reduced. The total volume of input data is 336 MB (192 +MB of processed science image, 48 MB of input mask, 64 MB of static +sky image and 32 MB of static sky weight map) while the output data is +128 MB (64 MB static sky, 32 MB weight map, and 32 MB difference +image). Thus, we require a total of 464 MB network I/O, which implies +an I/O period of 9.3 seconds. + +\begin{table} +\begin{center} +\caption{Data Throughput for 4 Scenarios \label{throughput}} +\begin{tabular}{lrrrr} +\hline +\hline +& +\multicolumn{1}{c}{Random / Standard} & +\multicolumn{1}{c}{Random / Minimal} & +\multicolumn{1}{c}{Optimal / Standard} & +\multicolumn{1}{c}{Optimal / Minimal} \\ +\hline +Phase 2 per-node network I/O & 15.2 s & 6.6 s & 3.7 s & 2.5 s \\ +Phase 2 per-node disk I/O (read) & (5.6 s) & (2.3 s) & 5.0 s & 1.7 s \\ +Phase 2 per-node disk I/O (write) & (0.8 s) & (0.4 s) & 0.8 s & 0.4 s \\ +Phase 2 CPU total & 14 s : 860 GHz & 23 s : 520 GHz & 20 s : 600 GHz & 25 s : 480 GHz \\ +Phase 4 per-node I/O & 16 s & 9.3 s & & \\ +Phase 4 CPU total & 14 s : 490 GHz & 20 s : 390 GHz & & \\ +Phase 2 switch load & 6.1 GB/s & 2.7 GB/s & 1.5 GB/s & 1.0 GB/s \\ +Phase 4 switch load & 0.8 GB/s & 0.5 GB/s & 0.8 GB/s & 0.5 GB/s \\ +Phase 2 to Phase 4 switch load & 1.1 GB/s & 0.6 GB/s & 1.1 GB/s & 0.6 GB/s \\ +Summit to Phase 2 switch load & 0.5 GB/s & 0.5 GB/s & 0.5 GB/s & 0.5 GB/s \\ +\hline +\end{tabular} +\end{center} +\end{table} + +\subsubsection{Switch I/O Requirements} + +The switch I/O requirements are defined by the total number of bytes +per second serviced by the two switches in the system. For the +analysis of the Switch I/O requirements, the choice of data +distribution again has a major impact. We again test the four +scenarios discussed above: Random Data Distribution, Random / Minimal, +Optimal Data Distribution, and Optimal / Minimal. + +\paragraph{Random / Standard Data Scenario} + +In the Random Data Distribution scenario, each OTA node needs to read +a total of 560 MB from the network and write a total of 200 MB every +30 seconds. With 240 OTA nodes, this corresponds to a total bandwidth +of 6080 MB/sec, or 49 Gb/sec. Note that this includes the bandwidth +needed to copy data from the summit and make two copies on the OTA +machines, as well as the bandwidth to send the processed image +portions to the Phase 4 machines. The Phase 4 processing adds an +additional 320 MB of network I/O per Sky-Cell group, and there are +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 +attached to separate switches. An additional bandwidth requirement is +derived by the need to exchange data between these switches in for +Phase 4. The total amount of data exchanged between these switches is +480 MB per Sky-cell, for a total bandwidth of 1120 MB/sec. In +addition, the connection to the summit is a single, separate line +which needs to support the bandwidth requirement of copying all intial +raw images. In our simple model, each raw image is copied twice, +accounting for a total of 15360 MB every 30 seconds, or a bandwidth +load of 512 MB/sec. (Note that this last is double the actual +bandwidth requirement to the summit: a dedicated local circular buffer +would reduce the need for the second copy to come directly from the +summit.) + +\paragraph{Random / Minimal Data Scenario} + +In the Random / Minimal Scenario, the data volumes are significantly +reduced. The total Phase 2 bandwidth contribution is 332 MB over 30 +seconds for 240 nodes (2656 MB/sec) and the residual Phase 4 bandwidth +load is 224 MB per Sky cell over 30 seconds (522 MB/sec). The +inter-switch communication is now 240 MB per sky cell over 30 seconds, +or 560 MB/sec. + +\paragraph{Optimal / Standard Data Scenario} + +In the Optimal Data Distribution, the Phase 2 network bandwidth is +reduced significantly to 184 MB per OTA node, for a total of +1.5GB/sec, while the Phase 4 network bandwidth remains unchanged at +750 MB/sec. The inter-switch communication also remains the same at +1.12 GB/sec. + +\paragraph{Optimal / Minimal Data Scenario} + +In the Optimal / Minimal Scenario, the total Phase 2 network bandwidth +drops to 124 MB per OTA node, for a total of 1.0GB/sec, while the +Phase 4 network bandwidth is 552 MB/sec. The inter-switch +communication remains the same as the Random/Minimal Scenario at 560 +MB/sec. + +\begin{table}[t] +\begin{center} +\caption{\label{NP2} Phase 2 load per major frame (12000 GHz-sec)} +\begin{tabular}{lrrrr} +\hline +\hline +& Random/Standard +& Random/Minimal +& Optimal/Standard +& Optimal/Minimal \\ +\hline +network I/O (GB) & 182 & 80 & 44 & 30 \\ +PS-1 & & & & \\ + I/O (cpu-sec) & 3640 & 1600 & 880 & 600 \\ + CPU (cpu-sec) & 4000 & 4000 & 4000 & 4000 \\ + \# cpus & 64 & 47 & 41 & 38 \\ +PS-4 & & & & \\ + I/O (cpu-sec) & 1820 & 800 & 440 & 300 \\ + CPU (cpu-sec) & 2000 & 2000 & 2000 & 2000 \\ + \# cpus & 127 & 93 & 81 & 77 \\ +\hline +\end{tabular} +\end{center} +\end{table} + +\begin{table}[b] +\begin{center} +\caption{\label{NP4} Phase 4 load per major frame (7800 GHz-sec)} +\begin{tabular}{lrr} +\hline +\hline +& Standard +& Minimal \\ +\hline +network I/O (GB) & 48 & 28 \\ +PS-1 & & \\ + I/O (cpu-sec) & 960 & 557 \\ + CPU (cpu-sec) & 2600 & 2600 \\ + \# cpus & 30 & 26 \\ +PS-4 & & \\ + I/O (cpu-sec) & 480 & 278 \\ + CPU (cpu-sec) & 1300 & 1300 \\ + \# cpus & 59 & 53 \\ +\hline +\end{tabular} +\end{center} +\end{table} + +\subsubsection{Conclusions} + +Table~\ref{throughput} presents one way of analysing the hardware +requirements, making a specific set of assumptions about the number of +nodes for the two phases and the expected network and disk +bandwidths. The important conclusion in this analysis is the implied +number of GHz per processor, given the assumptions laid out. +Phase 2 is specified to have 240 OTA nodes, while Phase 4 is specified +to have roughly 60 static sky nodes. The range of Phase 2 CPU +requirements implies that each CPU needs to have speeds in the range +of 2.0 - 3.6 GHz, which sound very plausible for the year 2007, since +these apply to PS-4. + +Another way to represent this information is to use the total number +of MB I/O and the total number of GHz-sec required for the two stages, +confront these with an assumption for the bandwidth per network +adapter and an assumption for the CPU speed and use those numbers to +calculate the minimum number of nodes (CPUs) needed to sustain the +timing requirements. There are quite a few parameters and options to +choose from. We have assumed that for PS-1, the time between major +frames (4 images combined in Phase 4) is 120 seconds, and 30 seconds +for PS-4. We have also assumed that each CPU has one network adapter +associated with it, and use the numbers of 50 MB/sec for PS-1 era +network adapters and 100 MB/sec for the PS-4 network adapters (since +there has been some steady improvement in GigE hardware over the past +year). We have also assumed each PS-1 CPU is rated at 3 GHz and those +for PS-4 are rated at 6 GHz (somewhat conservative since 3 GHz +machines are already available). Tables~\ref{NP2} and \ref{NP4} show +the load and resulting number of nodes for both Phase 2 and Phase 4 +for both the PS-1 and PS-4 assumptions, using the I/O numbers for all +of the scenarios above. Note that in these discussions, we make the +idealized assumption that the computational and I/O portions of each +process are completely serial. As a result, the CPU is completely +used to perform the I/O during the I/O phase, avoiding any concern +about I/O load on the processor during analysis. + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\section{Test Verification} + +A testing regime shall be implemented to demonstrate the working state +of the provided software. Certain tests as specified shall be +performed by MHPCC, with code release contingent on success. Other +specified tests will be performed by IfA to verify the validity of the +implemented algorithms. The tests include: software configuration +tests, software integrity tests, basic unit tests, and detailed +functional analysis. + +\subsection{Software Configuration Tests} + +MHPCC shall test the validity of the software configuration, +specifically to check that the code can be compiled on the specified +platforms and that the compilation produces no errors or warnings, +except as noted and allowed. + +\subsection{Software Integrity Tests} + +MHPCC shall test the integrity of the software, specifically to check +that the code does not produce memory leaks, segmentation faults. + +\subsection{Basic Unit Tests} + +MHPCC shall perform basic unit tests with sample input data and known +output results, including invalid input data to test error handling. +These tests should exercise the complete range of module options. + +\subsection{Detailed Functional Analysis} + +IfA shall perform detailed tests with a wide range of input data and +compare the results with existing software system. + +\subsection{Test Verification Matrix} + +\subsubsection{Pan-STARRS IPP Library} + +See Appendix A \& B of the IPP Library SDR (PSDC-430-007) for the test +verification matricies for the Pan-STARRS IPP Library + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\section{Appendices} + +\bibliographystyle{plain} +\bibliography{panstarrs} +\end{document} +