IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Changeset 1067


Ignore:
Timestamp:
Jun 21, 2004, 10:35:17 PM (22 years ago)
Author:
eugene
Message:

major edits to the hardware section.
cleanups of the TBDs elsewhere.

File:
1 edited

Legend:

Unmodified
Added
Removed

  • trunk/doc/design/ippSRS.tex

    r882 r1067  
    1 %%% $Id: ippSRS.tex,v 1.4 2004-06-05 00:49:48 eugene Exp $
     1%%% $Id: ippSRS.tex,v 1.5 2004-06-22 08:35:17 eugene Exp $
    22\documentclass[panstarrs]{panstarrs}
    33
    … …  
    7373
    7474\paragraph{``Should''}  When used in this specification, the word
    75 ``should'' refers to a desired chracteristic of a system component or
     75``should'' refers to a desired characteristic of a system component or
    7676the complete system.
    7777
    … …  
    111111
    112112\item Accept raw images from the summit at a sustained rate of 1
    113  exposure per 30 seconds.
    114 
    115 \item Accept metadata from the summit at a sustained rate of \tbd{XXX
    116 MB / sec}.
    117 
    118 \item Produce high-quality master calibration images from the raw
    119   calibration images.  The master calibration images must not
    120   introduce systematic uncertainties greater than \tbd{0.2\%}.
    121   \tbd{Requirements on the speed of processing the calibration
    122   images.}
    123 
    124 \item Pre-process the science images with the high-quality master
    125   calibration images.
     113 exposure (2~GB) per 30 seconds.
     114
     115\item Accept metadata from the summit at a sustained rate of \tbr{1 MB
     116 per second}.
     117
     118\item Produce master calibration images from the raw calibration
     119 images.  The master calibration images must not introduce systematic
     120 uncertainties in the photometry greater than \tbr{0.2\%}.
     121
     122\item Pre-process the science images with the master calibration
     123  images.
    126124
    127125\item Merge multiple pre-processed science images -- from multiple
    128   telescopes or from sequential, dithered exposures -- into single,
    129   cleaned, stacked images with corresponding signal-to-noise maps.
    130 
    131 \item Subtract a static sky image from the cleaned, stacked images to
    132   produce an image of only the transient objects.
    133 
    134 \item Excise the significant transients and outliers from the
    135   pre-processed science images.  \tbd{how to handle variable stars?}
    136 
    137 \item merge the cleaned images into the static sky image, and
    138   update the corresponding exposure (S/N) maps.
     126 telescopes or from sequential, dithered exposures -- into stacked
     127 images with corresponding signal-to-noise maps.  Pixels from the
     128 input images which are outliers for the ensemble of corresponding
     129 pixels must be excised.
     130
     131\item Subtract a static sky image from the stacked images to produce
     132 an image of only the transient objects.
     133
     134\item Excise transients and outliers which exceed a user-configurable
     135 threshold in the subtracted image from the pre-processed science
     136 images.
     137
     138\item Merge the cleaned images into the static sky image, and update
     139 the corresponding exposure (S/N) maps.
    139140
    140141\item Detect and measure parameters of objects on the four types of
    141   images: pre-processed images, the stacked image, the difference
    142   image, and the static sky image.
     142 images: pre-processed images, the stacked image, the difference
     143 image, and the static sky image.
    143144
    144145\item Determine astrometry of the detected objects relative to an
    145   astrometric reference to an accuracy of \tbd{30 mas}, with a limit of
    146   \tbd{xxx} on the outliers.
    147 
    148 \item Determine photometry of the detected objects relative to a
    149   photometric reference to an accuracy of \tbd{5 millimag} relative
    150   photometry and \tbd{10 millimag} absolute photometry in photometric
    151   weather.  \tbd{before vs after PS-1 AP Surver} \tbd{bright vs faint
    152   errors} with a limit of \tbd{xxx} on the outliers.  \tbd{limit
    153   depends on filter}
     146 astrometric reference.  For the Commissioning phase of PS-1, the
     147 astrometric calibration will be limited by the determination of the
     148 optical model of the focal plane, and may be as poor as \tbr{750
     149 mas}.  For the AP reference construction phase of PS-1, after the
     150 optical model has been measured, the astrometry solution must be
     151 limited by the reference catalog in use, and will be in the vicinity
     152 of \tbr{75 mas (UCAC) - 250 mas (USNO B1.0)}.  After the construction
     153 of the AP astrometric reference catalog, the accuracy will be limited
     154 by atmospheric variations, and must be no worse than \tbr{50 mas},
     155 with a goal of \tbr{10 mas}.
     156
     157\item Determine photometry of the detected objects, both within an
     158 internal photometric system and in terms of appropriate external
     159 photometric reference systems.  For the Commissioning phase, the
     160 accuracy of the photometric calibration will be limited by the
     161 quantity and quality of the standard star observations, and the
     162 consistency of the flat-field images across the camera; the scatter
     163 must be less than \tbr{25 millimags}.  During the AP reference
     164 construction phase of PS-1, after the flat-field correction has been
     165 measured, the photometric accuracy will be limited by the standard
     166 star observations, the zero-point determinations, and in the case of
     167 calibration to the external standard, the color corrections.  The
     168 photometric accuracy in this stage must be better than \tbr{10
     169 millimags}.  After the construction of the AP Reference Catalog, the
     170 photometric accuracy will be limited by knowledge of the flat-field,
     171 variations in the atmosphere across the field, and the reference
     172 catalogs.  The photometric scatter in photometric weather must be
     173 better than \tbd{5 millimag} for relative photometry (relative to the
     174 internal filter system) and \tbd{10 millimag} for absolute photometry
     175 (relative to other filter systems such as the SDSS filters).
    154176
    155177\item Produce a high-quality astrometric reference catalog from the
    156   extracted objects on a time-scale of 6 months.  The astrometric
    157   reference must have an absolute accuracy of \tbd{30 mas} and a local
    158   relative accuracy of \tbd{10 mas}.  Proper motions of detected
    159   objects with distances greater than 1000 AU must be determined with
    160   an accuracy of \tbd{XXX mas / year}.
     178  extracted objects within 6 months of the end of the AP Survey.  The
     179  astrometric reference must have an absolute accuracy of \tbr{30 mas}
     180  and a local relative accuracy of \tbr{10 mas}.  Proper motions of
     181  detected non-solar-system objects must be determined with an
     182  accuracy of \tbr{20 mas / year} for unsaturated, bright stars.
    161183
    162184\item Produce a high-quality photometric reference catalog from the
    163   extracted point-source objects on a time-scale of 6 months.  The
    164   photometric reference must have an consistency across the sky of
    165   \tbd{5 millimag} and an absolute calibration to the external system
    166   defined by \tbd{SDSS} of \tbd{10 millimag}.
     185  extracted point-source objects within 6 months of the end of the AP
     186  Survey.  The photometric reference must have an consistency across
     187  the sky of \tbr{5 millimag} and an absolute calibration to the
     188  external system (defined by \tbr{SDSS} and the CFHT Legacy Survey
     189  Standards) with an accuracy of \tbr{10 millimag}.
    167190
    168191\item Publish the static sky images to the Pan-STARRS published static
    … …  
    174197\item Provide access to external Pan-STARRS clients to the detected
    175198  objects on time-scales of \tbr{10 minute} after the image is
    176   obtained.\comment{this is a top-level science requirement.}
    177 
    178 \item Store the raw images for a particular period of, depending on
    179   the survey source of the data.  In PS-1, the AP and IVP Survey data
    180   must be stored for the lifetime of the project.  Other raw data must
    181   be store for \tbr{1 month}.
     199  obtained.\comment{this is derived from the top-level science
     200  requirement.}
     201
     202\item Store the raw images for a period of time which depends on the
     203  survey source of the data.  In PS-1, the AP and IVP Survey data must
     204  be stored for the lifetime of the project.  Other raw data must be
     205  stored for \tbr{1 month}.
    182206
    183207\item Store the detected objects for a period of time, depending on
    184208  the type of detection.  Transients from the P4$\Delta$ images may be
    185   excised after \tbr{6 monts}.
     209  excised after \tbr{6 months}.
    186210
    187211\end{enumerate}
    … …  
    198222complete set of image processing tasks, including both calibration and
    199223science image processing.  The IPP must respond to requests for data
    200 from client science pipelines.
     224from client science pipelines.  In the active state, the IPP must
     225respond to analysis priority requests issued by the IPP users.
    201226
    202227\subsubsection{Paused State}
    … …  
    209234\label{req:interactive-state}
    210235
    211 In interactive state, the IPP must accept imcoming data and metadata,
     236In interactive state, the IPP must accept incoming data and metadata,
    212237but must not automatically process the data.  The IPP must respond to
    213238user commands to initiate portions of the data analysis.
    … …  
    242267the delivered code must be in compliance with the language-independent
    243268UNIX operating system standard POSIX (Open Group Based Specifications
    244 Issue 6, IEEE Std 1003.1, 2003).
     269Issue 6, IEEE Std 1003.1, 2004).
    245270\item Source code files must use the UNIX line-break
    246271convention (line-feed only). 
    … …  
    259284
    260285Functions visible at global scope that are part of the public API must
    261 have names begining with \code{ps} and follow the naming conventions
     286have names beginning with \code{ps} and follow the naming conventions
    262287in the coding standard.  Functions visible at global scope but which
    263 are not part of the public interface must have names begining with
     288are not part of the public interface must have names beginning with
    264289\code{p_ps}.  Functions that are local to a file must \textit{not}
    265 start \code{ps} (or \code{p_ps}).
     290start with \code{ps} or \code{p_ps}.
    266291 
    267292Variables visible at global scope which are part of the public API
    268 must have names begining with \code{ps}, and follow the naming
     293must have names beginning with \code{ps}, and follow the naming
    269294conventions in the coding standard.  Variables that are visible at
    270295global scope but which are not part of the public interface must have
    271 names begining with \code{p_ps}.  Variables that are local to a file
    272 must \textit{not} start \code{ps} (or \code{p_ps}).
     296names beginning with \code{p_ps}.  Variables that are local to a file
     297must \textit{not} start with \code{ps} (or \code{p_ps}).
    273298
    274299The names of all enumerated types and C-preprocessor symbols (but not
    … …  
    281306
    282307When defining a function to convert from one type to another, the name
    283 must be of the form \code{psOldToAlloc}, e.g.\hfil\break
     308must be of the form \code{psOldToNew}, e.g.\hfil\break
    284309\code{psEquatorialToEcliptic} (\emph{not}
    285310\code{psEquatorial2Ecliptic}).
    … …  
    290315\textit{first}, following the pattern of \code{strcpy}; e.g.
    291316\begin{verbatim}
    292 void psAddToVector(restrict psVec *outVec, const restrict psVec *inVec,
    293                    int val);
     317void psVectorCopy(restrict psVector *out, const restrict psVector *in);
    294318\end{verbatim}
    295319
    … …  
    300324\item The constructor name should consist of the type name followed by
    301325\code{Alloc}; e.g. a type \code{psImage} would be created by a
    302 function
    303 \begin{verbatim}
    304 psImage *psImageAlloc(int nrow, int ncol);
    305 \end{verbatim}
    306 
    307 \item The type should be freed with a destructor named \code{typeFree}, e.g.
    308 \begin{verbatim}
    309 void psImageFree(psImage *img);
    310 \end{verbatim}
     326function \code{psImage *psImageAlloc();}.
     327
     328\item The type should be freed with a destructor named
     329\code{typeFree}, e.g.  \code{void psImageFree(psImage *image);}.
    311330
    312331\item The constructor must never return \code{NULL}, and no code calling the
    … …  
    344363\subsubsection{CSCI Deliverable}
    345364
    346 All final source code generated for the IPP is to be delivered via
    347 CVS, including the test code.  CVS revision history must be included
    348 and made available via CVS.
     365All final source code generated for the IPP must be delivered via CVS,
     366including the test code.  CVS revision history must be included and
     367made available via CVS.
    349368
    350369\subsubsection{Platform architectures and operating systems}
    … …  
    367386x86/Linux combination.
    368387
    369 All timing measurements are to execution time as measured on a
    370 \tbd{Reference Pan-Starrs Computation Node} and assumed to be not
    371 limited by network bandwidth.
     388\subsubsection{Timing measurements}
     389
     390Timing requirements specified in this document must be achieved on the
     391deployed Pan-STARRS analysis computers.
    372392
    373393\subsubsection{Software Configuration}
    … …  
    381401software elements.  The SCD provides a detailed description of the
    382402roles and responsibilities of these subsystems.  In brief, the IPP
    383 consists of a collection of science analysis stages, a set of
    384 architectural components which provide the infrastructure needed to
    385 run the analysis programs, and a collection of hardware on which all
    386 of the software elements exist.
     403consists of: a collection of science analysis programs which perform
     404the stages of the data analysis; a set of architectural components
     405which provide the infrastructure needed to run the analysis programs;
     406and a collection of hardware on which all of the software elements
     407exist and operate.
    387408
    388409The architectural components consist of:
    … …  
    395416 any temporary image data products produced by the IPP.  The Image
    396417 Server is required to meet all of the image storage needs identified
    397  in the top-level requirements above.  The Image Server must accept
    398  the incoming data and store it until it is no longer needed by other
    399  portions of the IPP.
     418 in the top-level requirements above.  The Image Server may also store
     419 large data files which do not contain imaging data.  The Image Server
     420 must accept the incoming data and store it until it is no longer
     421 needed by other portions of the IPP.
    400422
    401423\item {\bf Astrometry \& Photometry Database (AP):} This component is
    402   required to store and manipulate astronomical objects detected in
    403   various images, as identified above, including individual
    404   measurements of objects on the images, the summary information about
    405   those objects, and reference object data.
     424 required to store and manipulate astronomical objects detected in
     425 images processed by the IPP, including individual measurements of
     426 objects on the images, the summary information about those objects,
     427 and reference object data.
    406428
    407429\item {\bf Metadata Database:} This component is required to store the
    408   all other data which are neither image files nor astronomical object
    409   data.  The Metadata Database is the authoratative source for all
    410   metadata data, including metadata which may be duplicated elsewhere,
    411   such as in the headers of images in the image database.
     430 all other data which are neither image files nor astronomical object
     431 data.  The Metadata Database is the authoritative source for all
     432 metadata data, including metadata which may be duplicated elsewhere,
     433 such as in the headers of images in the image database.
    412434
    413435\item {\bf Controller:} In order to perform the analysis stages
    414   required by the IPP, it is necessary to use distributed computing
    415   processes on a large number of computers.  The Controller is
    416   required to manage the collection of analysis stages performed on
    417   these machines.
    418 
    419 \item {\bf Scheduler:}  This component is a decision-making mechanism
    420   required to guide the operation of the IPP: to evaluate the
    421   currently available collection of data, to identify the necessary
    422   analysis, and to assign the analysis tasks to the Controller.
     436 required by the IPP, it is necessary to use distributed computing
     437 processes on a large number of computers.  The Controller is required
     438 to manage the collection of analysis stages performed on these
     439 machines.
     440
     441\item {\bf Scheduler:} This component is a decision-making mechanism
     442 required to guide the operation of the IPP: to evaluate the currently
     443 available collection of data, to identify the necessary analysis, and
     444 to assign the analysis tasks to the Controller.
    423445
    424446\end{enumerate}
    … …  
    440462
    441463The IPP Image Server must store images on a distributed collection of
    442 computer disks.  Individual instinces of a file are only required to
     464computer disks.  Individual instances of a file are only required to
    443465be stored on a single machine (striping across computers is not a
    444466requirement). 
    … …  
    447469image on a specific machine.  If such a request cannot be honored (ie,
    448470the machine is down), the IPP Image Server must select an appropriate
    449 machine and notify the requesting agent of the new locations. 
    450 
    451 The IPP Image Server store multiple copies of each image, the number
    452 of copies specified independently for each by the user.
     471machine and notify the requesting agent of the new location. 
     472
     473The IPP Image Server must store multiple copies of each image upon
     474request, the number of copies specified independently for each file by
     475the user.
    453476
    454477The IPP Image Server must maintain a record of all image copies
    455478currently available in the repository.  This record must include the
    456479image name, location (which machine), the image size, and the state of
    457 the image. 
     480the image (available, locked, deleted).
    458481
    459482The IPP Image Server must lock images in the repository on request.
    … …  
    465488which it resides) upon request.
    466489
    467 The IPP Image Server must return a specified image upon request.
     490The IPP Image Server must provide a specified image upon request.
    468491
    469492The IPP Image Server must delete images in the repository on request.
    … …  
    475498MB/sec.
    476499
     500\tbd{archive lifetime}
     501
     502\tbd{reliability}
     503
     504\tbd{backups}
    477505
    478506\subsubsection{AP Database}
    … …  
    542570\item given detection, return source image data.
    543571
     572\item given detection, return object.
     573
    544574\item given $(RA,DEC)$, return all images overlapping coordinate.
    545575
    … …  
    552582  magnitudes based on calibration information.
    553583
    554 \item given a collection of detections, determine the object avergae
    555   magnitude.
     584\item given a collection of detections in a filter, determine the
     585  object average magnitude in that filter.
    556586
    557587\item given a collection of objects and detections, determine the
    … …  
    559589
    560590\item given a region, return all possible combinations of the object
    561   or detection magnitudes $(M1 - M2)$.
     591  or detection magnitudes $(M_1 - M_2)$.
    562592
    563593\item given a list of $(RA,DEC)$ entries, return all nearest objects. 
    … …  
    600630incoming rates.  The expected rates are listed in Table~\ref{APrates},
    601631along with the total data volume required for storage space over the
    602 PS-1 lifetime.  The AP Database must be able to keep up with these
    603 rates. 
     632PS-1 lifetime. 
    604633
    605634\tbd{archive lifetime}
    … …  
    611640\subsubsection{Metadata Database}
    612641
    613 \tbd{this section needs to be reviewed and revised}
     642\begin{table}
     643\begin{center}
     644\caption{Metadata Classes\label{, and the while
     645the metadata}}
     646\begin{tabular}{l}
     647\hline
     648\hline
     649\hline
     650raw images \\
     651pending images \\
     652master detrend images \\
     653processed images \\
     654static sky images \\
     655detrend residuals \\
     656object detection statistics \\
     657master detrend creation statistics \\
     658astrometry residuals \\
     659warping statistics \\
     660processing timing \\
     661software installation information \\
     662software configuration information \\
     663\hline
     664\end{tabular}
     665\end{center}
     666\end{table}
    614667
    615668The IPP requires a Metadata Database to store and provide access to
    616669metadata of various types and from various sources.  Metadata in the
    617 context of the IPP represents all data which is not included in the
    618 two data stores discussed above (Images and Detection/Objects).
     670context of the IPP corresponds to all data which is not included in
     671the two data stores discussed above (Images and Detection/Objects).
    619672Metadata is generated at the telescope and during the various analysis
    620673stages
    … …  
    624677master), for the extracted object lists.  Metadata describing the
    625678environmental conditions at the telescope must also be stored and
    626 provided as needed. 
    627 
    628 If analysis results are exchanged via the metadata database, it must
    629 provide access to the queried data on timescales of $<2$ seconds to
    630 avoid slowing down the analysis systems.
    631 
    632 \tbd{need to extract specific requirements from this}
    633 
    634 \tbd{volume requirements}
    635 
    636 \tbd{queries}
    637 
    638 \tbd{description of images belong in the Metadata database, location
    639   of images is in the Image server}
    640 
    641 \paragraph{Configuration Database}
    642 
    643 The IPP requires a Configuration Database to store and provide access
    644 to information about the IPP itself.  Examples of data in the
    645 configuration database include the default parameters for the various
    646 analysis programs, the description of the computing environment, the
    647 process status information, etc.  \tbd{part of metadata database?}.
    648 
    649 \tbd{some information must have access limited to specific responsible
    650   people.  ie, software / hardware configuration $\rightarrow$ sysadmin;
    651   science parameters $\rightarrow$ science team.}
     679provided as needed.  Table~\ref{metadata} lists the classes of
     680metadata which must be stored by the Metadata Database.
     681
     682If analysis results are exchanged between analysis stages via the
     683Metadata Database, it must provide access to the queried data on
     684timescales of $<2$ seconds to avoid slowing down the analysis systems.
     685
     686The Metadata Database must store the metadata for the lifetime of the
     687project.  The Metadata Database must be capable of accepting a total
     688data volume after 2 years of operation of 128 GB.
     689
     690The Metadata Database must respond to simple queries which return the
     691data in the categories listed in Table~\ref{metadata} based on the
     692primary data key and with basic constraints of time ranges and other
     693simple conditional constraints.
     694
     695The Metadata must store descriptive information about the raw images
     696received from the summit and the current state of the data processing.
     697The Metadata must also store descriptive information for each of the
     698static sky images currently available. 
     699
     700The IPP requires configuration information defining the organization
     701and configuration of the IPP itself.  The Metadata database must store
     702the configuration information with restricted access so that only
     703specific people may change the information.  Examples of configuration
     704data include the default parameters for the various analysis programs,
     705the description of the computing environment, and the process status
     706information, etc.  The Metadata Database must restrict access to the
     707scientific parameters to a different group from the software and
     708hardware configuration parameters.
    652709
    653710\subsubsection{Controller}
    … …  
    661718
    662719The IPP Controller must detect computers which crash or stop
    663 responding.
     720responding and set their state to {\tt dead}.
    664721
    665722The IPP Controller must attempt to re-establish communication with
    … …  
    674731unavailable, the IPP Controller must attempt to run the task on
    675732another node.  If the node is available, the IPP Controller must
    676 attempt to run the next task when the current task is completed.
     733attempt to run a given task only if no higher-priority tasks are
     734available and no task is currently being executed.
    677735
    678736The IPP Controller must monitor the output from the task and write it
    679 to an associated log file.
    680 
    681 The IPP Controller must monitor the execution status of the task and
    682 perform the following actions:
     737to an associated log destination.
     738
     739The IPP Controller must monitor the execution status of each task
     740currently executing on a node and perform the following actions:
    683741\begin{enumerate}
    684742\item identify the task as successful if it has a valid exit status.
    … …  
    704762\subsubsection{Scheduler}
    705763
    706 The IPP Scheduler intiates analysis tasks which it must send to the
     764The IPP Scheduler initiates analysis tasks which it must send to the
    707765IPP Controller.
    708766
    … …  
    712770
    713771The IPP Scheduler must refer to several input data sources to decide
    714 what tasks to intiate.  These data sources include the IPP Metadata
     772what tasks to initiate.  These data sources include the IPP Metadata
    715773Database, the Summit Metadata Database, and User requests. 
    716774
    … …  
    726784
    727785When the IPP Scheduler is placed in the {\em paused state}, it must
    728 only intiate User-requested tasks.
     786only initiate User-requested tasks.
    729787
    730788When the IPP Scheduler is placed in the {\em interactive state}, it
    731 must intiate User-requested tasks as well as data transfer tasks.
     789must initiate User-requested tasks as well as data transfer tasks.
    732790
    733791When the IPP Scheduler is placed in the {\em automatic state}, it must
    734 intiate the most appropriate task based on the inputs.
     792initiate the most appropriate task based on the inputs.
    735793
    736794The IPP Scheduler must receive the exit status of tasks from the IPP
    … …  
    755813group.
    756814
    757 The science image analysis stages must perform their analyses quickly
    758 enoough to keep up with the incoming data stream.  The required
     815The science image analysis stages must perform their analysis quickly
     816enough to keep up with the incoming data stream.  The required
    759817processing time is derived from the rate at which science images are
    760818obtained by PS-1.  At a minimum, the Science Image Analysis must keep
    … …  
    764822night within 12 hours. 
    765823
    766 The maximum latency between the aquisition of an image and the
     824The maximum latency between the acquisition of an image and the
    767825completion of the science image analysis is set by the science
    768826requirements of the fast transient recovery programs.  The science
    … …  
    786844extract bright stars from the image.  This extraction must be done in
    787845less than \tbr{1 second}.  The total number of stars and size of the
    788 bright-star aquisition box must be a user-configurable parameter.
     846bright-star acquisition box must be a user-configurable parameter.
    789847
    790848In order for blind astrometry of an image to succeed, it is necessary
    … …  
    796854between the science image to be processed and the static sky images.
    797855
    798 The overlaps must overestimated by a small amount so that errors in
     856The overlaps must be overestimated by a small amount so that errors in
    799857astrometry at Phase 1 will not cause any valid static sky / science
    800858image pairs to be missed.  The amount of overlap must be a
    … …  
    802860
    803861Sky cells which do not have sufficient science image overlap \tbd{$<
    804 5\%$} must be excluded.
    805 
    806 It is not unusual that an image be obtained with invalid coordinates
     8625\%$} must be excluded from the overlap table.
     863
     864It is not unusual for an image to be obtained with invalid coordinates
    807865or without any valid stars.  For example, the telescope control system
    808866may make an error and report the wrong time or coordinates.  Or, the
    809867image may be obtained in exceptionally poor conditions with no
    810868detected stars.  Phase 1 must return a descriptive error message in
    811 these conditions. 
     869these conditions.
    812870
    813871\subsubsection{Phase 2 : image reduction}
    … …  
    816874the detector are processed to remove instrumental signatures. 
    817875
     876The Phase 2 analysis stage must consult the processing recipe to
     877define the necessary analysis steps performed by the Phase 2 stage.
     878
    818879Phase 2 must perform the analysis steps only if required by the
    819 processing recipe.  The processing recipe must respect exposure time
    820 and background flux limits to select certain stages.
     880processing recipe.  The processing recipe must define the stages to be
     881executed with optional exposure time and background flux limits to
     882require or exclude select certain stages.
     883
     884In the discussion below, various steps specify that the values are
     885user-configurable parameters.  These parameters must be stored in and
     886extracted from the Metadata Database.
    821887
    822888\paragraph{Detrend Image Convolutions}
    … …  
    835901
    836902The Phase 2 analysis must use the OT kernel to grow the traps in the
    837 raw bad pixel mag. 
     903raw bad pixel map. 
    838904
    839905The Phase 2 analysis must mask saturated pixels and a user-specified
    … …  
    845911\paragraph{Bias correction via overscan subtraction}
    846912
    847 Phase 2 must be perform bias subtraction on the image. 
    848 
    849 Phase 2 must choose the bias subtraction method and applied statistics
    850 based on a user-configured parameter. 
     913Phase 2 must perform bias subtraction on the image.
     914
     915Phase 2 must choose the bias subtraction method and analysis statistic
     916based on the user-configured parameters.
    851917
    852918The bias correction must be measured from the image overscan region.
    … …  
    861927
    862928\item subtract a 1-D bias which varies along the overscan.  The function to be used must include
    863 a spline or a chebychev polynomial derived from the data values along
     929a spline or a Chebychev polynomial derived from the data values along
    864930the overscan, as specified by the user parameters.
    865931
    … …  
    870936The statistic used to calculate the overscan constant or the inputs to
    871937the spline and polynomial fits must be derived from groups of pixels
    872 on the basis of one of several statistics, as specified by the user
    873 parameters.  The choice of statistics must include the sample and
    874 robust mean, median, and modes.
     938on the basis of one of several possible statistics, as specified by
     939the user parameters.  The choice of statistics must include the sample
     940and robust mean, median, and modes.
    875941
    876942In the case of a single constant, all of the overscan pixel values are
    … …  
    878944functional representation, the input values to the fit must represent
    879945the coordinate along the overscan, with the statistic derived from the
    880 pixels in the perpedicular direction at each location. 
     946pixels in the perpendicular direction at each location. 
    881947
    882948If specified in the user parameters, sigma-clipping must be performed
    … …  
    903969\paragraph{Flat-field correction}
    904970
    905 The Phase 2 analysis must divide by the provided flat-field image. 
     971The Phase 2 analysis must divide the science image by the provided
     972flat-field image.
    906973
    907974The division must handle zero-valued pixels in the flat-field image
    908 without raising floating point exceptions.
     975without raising floating point exceptions, setting the corresponding
     976bit value in the mask.
    909977
    910978The flat-field images must be appropriately normalized (see section
    … …  
    9411009bit value in the mask.
    9421010
    943 The Phase 2 analysis must extend the masked region be a
    944 user-configurable growth factor. 
     1011The Phase 2 analysis must extend the masked region by a
     1012user-configurable growth factor.
    9451013
    9461014The Phase 2 analysis must perform the cosmic ray detection only if it
    … …  
    9531021
    9541022The object detection must detect all objects above a user-configured
    955 threshold. \tbd{valid range for the threshold?}  The detection
    956 threshold must be a function of the average background flux or the
    957 image noise map.
     1023threshold. The threshold must be a positive value; negative values
     1024must invoke an error.  The detection threshold must optionally be a
     1025function of the average background flux or the local noise level.
     1026
     1027The object detection must measure the following object parameters:
     1028\begin{enumerate}
     1029\item object centroid and position errors
     1030\item an extended object position ($x_g, y_g$)
     1031\item instrumental PSF magnitude and error
     1032\item local background level and error
     1033\item second moments ($\sigma_{\rm min}, \sigma_{maj}$) of the object
     1034  and their covariance matrix
     1035\end{enumerate}
     1036
     1037Minimal object classification must be performed to distinguish objects
     1038which are consistent with a single PSF, objects which are
     1039inconsistently large, objects which are inconsistently small, and
     1040objects which are saturated.
     1041
     1042The resulting collection of detected objects must be saved along with
     1043the relevant image metadata (\ie filter, exposure time, etc).
     1044
     1045\paragraph{Astrometry}
     1046
     1047The Phase 2 analysis must match the detected objects with known
     1048astrometric reference objects.
     1049
     1050The astrometric reference object coordinates must be adjusted for
     1051proper motion.
     1052
     1053The reference and detected object coordinates must be fit to determine
     1054astrometric parameters for the individual OTAs. 
     1055
     1056The OTA astrometric parameters must include Chebychev polynomials of the
     1057coordinates up to 3rd order.
     1058
     1059The fitted number of polynomial orders must be a user-configured
     1060parameter. 
     1061
     1062The Cell astrometric parameters must not be allowed to vary in the
     1063fit. 
     1064
     1065The fit must be robust, rejecting outlier matches (either stars with
     1066poorly determined proper motion or spurious matches). 
     1067
     1068The resulting astrometric solution must be consistent across the OTA
     1069field to within \tbr{300 milli-arcsec}.
     1070
     1071\paragraph{Postage Stamps}
     1072
     1073The Phase 2 analysis must extract subrasters (`postage stamps')
     1074surrounding a user-specified list of coordinates from the flattened
     1075images.
     1076
     1077The postage stamp images must be saved in the IPP Image Server.
     1078
     1079\subsubsection{Phase 3 : exposure analysis}
     1080
     1081The Phase 3 analysis must use the objects detected in Phase 2, matched
     1082with a user-specified reference photometry catalog, to determine the
     1083image photometric zero point and zero-point variations across the
     1084field. 
     1085
     1086If zero-point variations are significant \tbd{level TBD}, the
     1087zero-point variations must be modeled with a Chebychev polynomial
     1088correction of order 3 or less.
     1089
     1090The photometric nature of the FPA image must be categorized
     1091\tbd{numerical scale?} on the basis of the zero-point consistency, the
     1092transparency compared with recent long-term measurements in the
     1093filter, and the external indicators of photometricity.
     1094
     1095The Phase 3 analysis must use the objects detected in Phase 2, matched
     1096with an appropriate astrometric reference catalog, to improve the
     1097distortion model used for the image.
     1098
     1099The resulting astrometric accuracy must be limited by the astrometric
     1100reference catalog, ie, 250 mas for USNO-B1.0.
     1101
     1102\subsubsection{Phase 4 : image combination}
     1103
     1104Phase 4 is the image combination stage, in which multiple images of
     1105the same portion of the sky are merged and confronted with the static
     1106sky image.  Requirements for the different steps of the process are
     1107given below.
     1108
     1109\paragraph{Extract image pixels}
     1110
     1111The Phase 4 analysis must determine the corresponding set of image
     1112pixels for a given sky cell.
     1113
     1114The corresponding image pixels must be extracted from the input
     1115images, using the astrometric information for each OTA and Cell to
     1116determine the exact overlaps.
     1117
     1118The Phase 4 analysis must not miss any pixels in this match, and it
     1119must read no more than 20\% more pixels than necessary from the input
     1120images.
     1121
     1122The Phase 4 analysis must skip any sky cells with fewer than 5\% of
     1123their pixels overlapping the input images.
     1124
     1125\paragraph{Transform pixel coordinates}
     1126
     1127Pixels which have been extracted from the input images must be mapped
     1128to the corresponding pixels in the sky image.
     1129
     1130The transformation must be based on the measured astrometric solution
     1131for the input images relative to the reference catalog used to
     1132generate the static sky image.
     1133
     1134This warping must use a locally-linear astrometric solution.
     1135
     1136The output image must maintain photometric consistency with the input
     1137image to within 0.2\%. 
     1138
     1139\tbd{interpolation?  does interpolation method choice risk losing flux?}
     1140
     1141\paragraph{Flux matching}
     1142
     1143The Phase 4 analysis must determine appropriate photometry scaling
     1144factors needed to combine the images photometrically.
     1145
     1146\tbd{is flux matched automatically by calibration?}
     1147
     1148\paragraph{Image outlier pixel rejection}
     1149
     1150When multiple images are combined, the group of input pixels which
     1151contribute to an output pixel must be examined and pixels from the
     1152group of images which are inconsistent with the ensemble \tbd{how
     1153much?} must be identified and flagged. 
     1154
     1155This outlier rejection must be performed optionally.
     1156
     1157\tbd{for moving objects and images which are not simultaneous, do we
     1158  identify the moving objects?}
     1159
     1160\tbd{use the spatial information?  fit a 2-D Nth order polynomial to
     1161  the collection of pixels and then look for outliers}
     1162
     1163\paragraph{Initial cleaned image}
     1164
     1165The resulting collection of pixels must be used to construct a single
     1166output image, cleaned of the outliers.
     1167
     1168\paragraph{PSF matching}
     1169
     1170The cleaned, combined image must be PSF matched with the static sky image.
     1171
     1172\paragraph{Image Subtraction}
     1173
     1174The static sky image must be subtracted from the stacked, cleaned
     1175image. 
     1176
     1177\tbd{what about different stellar colors?}
     1178
     1179\paragraph{Find objects in the image}
     1180
     1181The Phase 4 analysis must perform object detection on the difference
     1182images.
     1183
     1184All objects in the difference image must be detected and the pixels
     1185belonging to variable sources flagged in the input image. 
     1186
     1187The object detection must detect all objects above a user-configured
     1188threshold.  Both positive and negative objects must be detected; the
     1189specified threshold must define the absolute value of the detection
     1190thresholds.  The detection threshold must optionally be a function of
     1191the average background flux or the local noise level.
     1192
     1193The object detection must measure the following object parameters:
     1194\begin{enumerate}
     1195\item object centroid and position errors
     1196\item instrumental PSF magnitude and error
     1197\item local background level and error
     1198\item streak L, $\phi$, $\sigma_L$, $\sigma_\phi$
     1199\item second moments ($\sigma_{\rm min}, \sigma_{maj}$) and their covariance matrix
     1200\end{enumerate}
     1201
     1202Minimal object classification must be performed to distinguish objects
     1203which are consistent with a single PSF, objects which are
     1204inconsistent, and objects which are saturated. 
     1205
     1206The resulting collection of detected objects must be saved along with
     1207the relevant image metadata (\ie filter, exposure time, etc).
     1208
     1209\paragraph{Cleaned Input Image}
     1210
     1211The pixels flagged as being from the difference image sources must be
     1212masked in the input images. 
     1213
     1214A new, cleaned image must be constructed from the masked input images.
     1215
     1216\tbd{how to handle variable stars?}
     1217
     1218\paragraph{Find objects in the image}
     1219
     1220The Phase 4 analysis must perform object detection on the cleaned,
     1221summed image.
     1222
     1223The object detection must detect all objects above a user-configured
     1224threshold. The threshold must be a positive value; negative values
     1225must invoke an error.  The detection threshold optionally must be a
     1226function of the average background flux or the local noise level.
    9581227
    9591228The object detection must measure the following object parameters:
    … …  
    9641233\item local background level and error
    9651234\item second moments ($\sigma_{\rm min}, \sigma_{maj}$) and their
    966   covarience matrix
     1235  covariance matrix
     1236\item the Petrosian radius, magnitude, axis ratio, and angle
     1237\item the S\'ersic radius, magnitude, axis ratio, angle, and parameter $\nu$.
    9671238\end{enumerate}
    9681239
    … …  
    9741245the relevant image metadata (\ie filter, exposure time, etc).
    9751246
    976 \paragraph{Astrometry}
    977 
    978 The Phase 2 analysis must match the detected objects with known
    979 astrometric reference objects.
    980 
    981 The astrometric reference object coordinates must be adjusted for
    982 proper motion.
    983 
    984 The reference and detected object coordinates must be fit to determine
    985 astrometric parameters for the individual OTAs. 
    986 
    987 The OTA astrometric parameters must include Chebychev polynomials of the
    988 coordinates up to 3rd order.
    989 
    990 The fitted number of polynomial orders must be a user-configured
    991 parameter. 
    992 
    993 The Cell astrometric parameters must not be allowed to vary in the
    994 fit. 
    995 
    996 The fit must be robust, rejecting outlier matches (either stars with
    997 poorly determined proper motion or spurious matches). 
    998 
    999 The resulting astrometric solution must be consistent across the OTA
    1000 field to within \tbd{0.2 arcsec}.
    1001 
    1002 \paragraph{Postage Stamps}
    1003 
    1004 The Phase 2 analysis must extract subrasters (`postage stamps')
    1005 surrounding a user-specified list of coordinates from the flattened
    1006 images.
    1007 
    1008 The postage stamp images must be saved in the IPP Image Server.
    1009 
    1010 \subsubsection{Phase 3 : exposure analysis}
    1011 
    1012 The Phase 3 analysis must use the objects detected in Phase 2, matched
    1013 with a user-specified reference photometry catalog, to determine the
    1014 image photometric zero point and zero-point variations across the
    1015 field. 
    1016 
    1017 If zero-point variations are significant \tbd{level TBD}, the
    1018 zero-point variations must be modeled with a chebychev polynomial
    1019 correction of order 3 or less.
    1020 
    1021 The photometric nature of the FPA image must be categorized
    1022 \tbd{numerical scale?} on the basis of the zero-point consistency, the
    1023 transparency compared with recent long-term measurements in the
    1024 filter, and the external indicators of photometricity.
    1025 
    1026 The Phase 3 analysis must use the objects detected in Phase 2, matched
    1027 with an appropriate reference catalog, to improve the distortion model
    1028 used for this image.
    1029 
    1030 The resulting astrometric accuracy must be limited by the astrometric
    1031 reference catalog \tbd{30 mas for USNO?}
    1032 
    1033 \subsubsection{Phase 4 : image combination}
    1034 
    1035 Phase 4 is the image combination stage, in which multiple images of
    1036 the same portion of the sky are merged and confronted with the static
    1037 sky image.  Requirements for the different steps of the process are
    1038 given below.
    1039 
    1040 \paragraph{Extract image pixels}
    1041 
    1042 The Phase 4 analysis must determine the corresponding set of image
    1043 pixels for a given sky cell.
    1044 
    1045 The corresponding image pixels must be extracted from the input
    1046 images, using the astrometric information for each OTA and Cell to
    1047 determine the exact overlaps.
    1048 
    1049 The Phase 4 analysis must not miss any pixels in this match, and it
    1050 must read no more than 20\% more pixels than necessary from the input
    1051 images.
    1052 
    1053 The Phase 4 analysis must skip any sky cells with fewer than 5\% of
    1054 their pixels overlapping the input images.
    1055 
    1056 \paragraph{Transform pixel coordinates}
    1057 
    1058 Pixels which have been extracted from the input images must be mapped
    1059 to the corresponding pixels in the sky image.
    1060 
    1061 The tranformation must be based on the measured astrometric solution
    1062 for the input images relative to the reference catalog used to
    1063 generate the static sky image.
    1064 
    1065 This warping must use a locally-linear astrometric solution.
    1066 
    1067 The output image must maintain photometric consistency with the input
    1068 image to within 0.2\%.  \tbd{does interpolation method choice risk
    1069 losing flux?}
    1070 
    1071 \paragraph{Flux matching}
    1072 
    1073 The Phase 4 analysis must determine appropriate photometry scaling
    1074 factors needed to combine the images photometrically.
    1075 
    1076 \tbd{is flux matched automatically by calibration?}
    1077 
    1078 \paragraph{Image outlier pixel rejection}
    1079 
    1080 When multiple images are combined, the group of input pixels which
    1081 contribute to an output pixel must be examined and pixels from the
    1082 group of images which are inconsistent with the ensemble \tbd{how
    1083 much?} must be identified and flagged. 
    1084 
    1085 This outlier rejection must be performed optionally.
    1086 
    1087 \tbd{for moving objects and images which are not simultaneous, do we
    1088   identify the moving objects?}
    1089 
    1090 \tbd{use the spatial information?  fit a 2-D Nth order polynomial to
    1091   the collection of pixels and then look for outliers}
    1092 
    1093 \paragraph{Initial cleaned image}
    1094 
    1095 The resulting collection of pixels must be used to construct a single
    1096 output image, cleaned of the outliers.
    1097 
    1098 \paragraph{PSF matching}
    1099 
    1100 The cleaned, combined image must be PSF matched with the static sky image.
    1101 
    1102 \paragraph{Image Subtraction}
    1103 
    1104 The static sky image must be subtracted from the stacked, cleaned
    1105 image. 
    1106 
    1107 \tbd{what about different stellar colors?}
    1108 
    1109 \paragraph{Find objects in the image}
    1110 
    1111 The Phase 4 analysis must perform object detection on the difference
    1112 images.
    1113 
    1114 All objects in the difference image must be detected and the pixels
    1115 belonging to variable sources flagged in the input image. 
    1116 
    1117 The object detection must detect all objects above a user-configured
    1118 threshold. \tbd{valid range for the threshold?}  The detection
    1119 threshold must be a function of the average background flux or the
    1120 image noise map.
    1121 
    1122 The object detection must measure the following object parameters:
    1123 \begin{enumerate}
    1124 \item object centroid and position errors
    1125 \item instrumental PSF magnitude and error
    1126 \item local background level and error
    1127 \item streak L, $\phi$, $\sigma_L$, $\sigma_\phi$
    1128 \item second moments ($\sigma_{\rm min}, \sigma_{maj}$) and their covarience matrix
    1129 \end{enumerate}
    1130 
    1131 Minimal object classification must be performed to distinguish objects
    1132 which are consistent with a single PSF, objects which are
    1133 inconsistent, and objects which are saturated. 
    1134 
    1135 The resulting collection of detected objects must be saved along with
    1136 the relevant image metadata (\ie filter, exposure time, etc).
    1137 
    1138 \paragraph{Cleaned Input Image}
    1139 
    1140 The pixels flagged as being from the difference image sources must be
    1141 masked in the input images. 
    1142 
    1143 A new, cleaned image must be constructed from the masked input images.
    1144 
    1145 \paragraph{Find objects in the image}
    1146 
    1147 The Phase 4 analysis must perform object detection on the cleaned,
    1148 summed image.
    1149 
    1150 The object detection must detect all objects above a user-configured
    1151 threshold. \tbd{valid range for the threshold?}  The detection
    1152 threshold must be a function of the average background flux or the
    1153 image noise map.
    1154 
    1155 The object detection must measure the following object parameters:
    1156 \begin{enumerate}
    1157 \item object centroid and position errors
    1158 \item an extended object position ($x_g, y_g$)
    1159 \item instrumental PSF magnitude and error
    1160 \item local background level and error
    1161 \item second moments ($\sigma_{\rm min}, \sigma_{maj}$) and their
    1162   covarience matrix
    1163 \item the Petrosian radius, magnitude, axis ratio, and angle
    1164 \item the S\'ersic radius, magnitude, axis ratio, angle, and parameter $\nu$.
    1165 \end{enumerate}
    1166 
    1167 Minimal object classification must be performed to distinguish objects
    1168 which are consistent with a single PSF, objects which are
    1169 inconsistent, and objects which are saturated. 
    1170 
    1171 The resulting collection of detected objects must be saved along with
    1172 the relevant image metadata (\ie filter, exposure time, etc).
    1173 
    11741247\paragraph{Image Processing Q/A}
    11751248
    11761249Before the image is added to the static sky, it must pass Q/A tests.
     1250
     1251\tbd{how do we specify auotmatic Q/A tests? astrometry, photometry}
    11771252
    11781253\paragraph{Update static sky}
    … …  
    11861261
    11871262It is required that the {\em total} processing for each exposure by
    1188 the Pan-STARRS system not take longer than $n \times T_{\rm min}$,
    1189 where $T_{\rm min}$ is the minimum time between exposures (30 sec),
    1190 and $n$ is a small positive number.  Increasing $n$ results in a
    1191 proportionally higher expenditure on CPUs, hence it is strongly
    1192 desirable that $n \le 2$.
    1193 
    1194 Since we envision 4 OTAs (each 4k pixels, square) being processed by a
    1195 single CPU, we need Phase 4 to process 64 (input) Mpix in
    1196 approximately 30 sec (since Phase 4 is the most intensive, it should
    1197 receive the lion's share of the time budget), or 2 (input) Mpix per
    1198 second.
    1199 
    1200 \paragraph{Accuracies}
    1201 
    1202 Transformations/mappings from detector to sky must preserve both
    1203 photometric and astrometric accuracies:
    1204 \begin{itemize}
    1205 \item Relative photometric accuracy better than \tbd{0.005 mag}
    1206 \item Absolute photometric accuracy better than \tbd{0.02 mag}
    1207 \item Relative astrometric accuracy better than \tbd{0.01 arcsec}
    1208 \item Absolute astrometric accuracy better than \tbd{0.2 arcsec}
    1209 \end{itemize}
     1263the Pan-STARRS system not take longer than the time between a complete
     1264set of exposures. For PS-1, the primary mode of operation will use
     1265four exposures to form a complete set (major frame), with 30 second
     1266exposures times and 2 second readout times.  Thus, the complete Phase
     12674 analysis must be performed on average within 120 seconds, assuming a
     1268separate collection of computers are dedicated to the Phase 2
     1269analysis.
    12101270
    12111271\paragraph{Robustness}
    1212 
    1213 \tbd{what are the corresponding requirements?}
    12141272
    12151273It is essential that the static sky image (which may have been
    … …  
    12181276to an error upstream in the processing).
    12191277
     1278\tbd{what are the corresponding requirements?}
     1279
    12201280\subsubsection{Calibration Stages}
    12211281\label{mkcal}
     1282
     1283tbd{Requirements on the speed of processing the calibration images.}
    12221284
    12231285The Calibration analysis stages must construct the various types of
    … …  
    12411303which the master bias is applied to the input images.
    12421304
     1305Outlier residual images, those for which the residual bias and
     1306variance in the bias image are excessive ($> 1DN$), must be excluded
     1307from the input image stack the the bias image reconstructed.
     1308
    12431309\paragraph{dark images}
    12441310
    … …  
    12601326which the master dark is applied to the input images.
    12611327
     1328Outlier residual images, those for which the residual level and
     1329variance are excessive ($> 1DN$), must be excluded from the input
     1330image stack the the dark image reconstructed.
     1331
    12621332\paragraph{flat-field images}
    12631333
    … …  
    12841354images, in which the master flat-field is applied to the input images.
    12851355
     1356Outlier residual images, those for which the residual level and
     1357variance are excessive ($> 0.1$\%, or 1.02 times the Poisson limit of
     1358the flat-field image), must be excluded from the input image stack the
     1359the flat-field image reconstructed.
     1360
    12861361\paragraph{mask images}
    12871362
    … …  
    13321407The \code{fringe} calibration stage must construct residual images, in
    13331408which the master fringe image is applied to the input images, along
    1334 with all necessary preceeding calibration images.
     1409with all necessary preceding calibration images.
    13351410
    13361411The \code{fringe} calibration stage must measure the residual fringe
    13371412amplitude on the residual images.
    13381413
    1339 \paragraph{low-k sky models}
     1414\paragraph{low-spatial-frequency sky models}
    13401415
    13411416The \code{sky model} calibration stage must construct a sky model
    13421417image from a stack of raw night-time sky images.
     1418
     1419\tbd{details of the image construction to be specified}
    13431420
    13441421\paragraph{Flat-field correction frame}
    … …  
    13831460future Pan-STARRS calibration.  The generation of these catalogs is
    13841461inherently a research project, and will require human control and
    1385 intervention.  The IPP will be required to provide the data access,
     1462intervention.  The IPP is required to provide the data access,
    13861463manipulation and visualization tools needed to construct these
    13871464reference catalogs and to assess their quality.  In this section, we
    … …  
    13931470\begin{center}
    13941471\caption{Astrometric Reference Catalogs\label{AstroRefs}}
    1395 \begin{tabular}{lrrr}
    1396 \hline
    1397 \hline
    1398 Name       & scatter & depth & filters \\
    1399            & arcsec  & mag  &         \\
    1400 \hline
    1401 Hipparcos  & & & \\
    1402 Tycho2     & & & \\
    1403 UCAC       & & & \\
    1404 YBx        & & & \\
    1405 USNO-Bx    & & & \\
    1406 2MASS      & & & \\
     1472\begin{tabular}{lrrrrl}
     1473\hline
     1474\hline
     1475Name       & scatter limit   & proper  & depth   & Nstars    & filters \\
     1476           & (milli-arcsec)  & motion? &(mag)    & (millions) &         \\
     1477\hline
     1478Hipparcos  &   1             & 2       &  7.3    &    0.1     & V      \\
     1479Tycho2     &  10             & 1       & 11.5    &    2.5     & B,V    \\
     1480UCAC-2     &  20             & 1       & 16.0    &   48.0     & R      \\
     1481USNO-A2.0  & 250             & N/A     & 19.0?   &  526.2     & B,R    \\
     1482USNO-B1.0  & 200             & 20?     & 21.0    & 1042.6     & B,R    \\
     14832MASS      &  70             & N/A     & 15.0?   &  470.0     & J,H,K  \\
    14071484\hline
    14081485\end{tabular}
    … …  
    14131490reference on the basis of the observations obtained by the AP survey.
    14141491The IPP must provide the analysis tools needed to generate the master
    1415 astometric reference catalog.  Much of the required functionality is
     1492astrometric reference catalog.  Much of the required functionality is
    14161493covered by the AP Database.
    14171494
    … …  
    15341611
    15351612The required set of Pan-STARRS modules and their functionality is
    1536 specfied in the document `Pan-STARRS Image Processing Pipeline Modules
     1613specified in the document `Pan-STARRS Image Processing Pipeline Modules
    15371614Supplementary Design Requirements' (PSDC-430-xxx), and details of
    1538 specific apgorithms are specfied in the document `Pan-STARRS Image
     1615specific algorithms are specified in the document `Pan-STARRS Image
    15391616Processing Pipeline Algorithm Design Document' (PSDC-430-006).
    15401617
    1541 \subsection{PanSTARRS IPP Library}
     1618\subsection{Pan-STARRS IPP Library}
    15421619
    15431620In order to facilitate testing and development, and to encourage
    … …  
    16291706\subsubsection{Overview}
    16301707
    1631 \tbd{this section should be parred down a bit by referring more to the
    1632   hardware report}.
    1633 
    1634 \tbd{switch to passive voice (we will address foo $\rightarrow$ foo is
    1635 addressed)}
    1636 
    1637 This section discusses the Pan-STARRS Image Processing Pipeline (IPP)
    1638 PS-1 hardware requirements.  The hardware requirements addressed in
    1639 this section consist of:
     1708This section discusses the IPP PS-1 hardware requirements.  The
     1709hardware requirements addressed in this section consist of:
    16401710
    16411711\begin{itemize}
    … …  
    16471717\end{itemize}
    16481718
    1649 We will address the various hardware requirements by referring to the
    1650 assumed data processing and data organization scenarios discussed in
    1651 the document \tbd{Pan-STARRS IPP Hardware Report, PSDC-4xx-xx}.  The
    1652 organization of the data and certain aspects of the data processing
    1653 scheme have very large implications for the hardware requirements.  We
    1654 use the values from that report representing the minimum data volume
    1655 and the optimum data organization.  We address the data requirements
    1656 of the single-telescope Pan-STARRS-1 scenario based on the Design
    1657 Reference Mission \tbd{REF}.
     1719The report, `The Pan-STARRS Image Processing Pipeline Computational
     1720Challange' (PSDC-4xx-xx) discusses the assumptions and measurements
     1721made to determine the IPP computing requirements, for both the PS-1
     1722configuration and the PS-4 configuration, under multiple assumptions
     1723regarding the data volume.  The requirements in this section are
     1724derived from that report, and follow the minimal data volumne
     1725assumptions for PS-1.
    16581726
    16591727\begin{table}[b]
    … …  
    16641732\hline
    16651733Raw data           & 200 TB \\
    1666 static sky         & 256 TB \\
    1667 calibration frames &   5 TB \\
    1668 metadata db        & 0.3 TB \\
    1669 object db          &   4 TB \\
    1670 \hline
    1671 total              & 466 TB \\
     1734static sky         & 235 TB \\
     1735calibration frames & 1.8 TB \\
     1736metadata db        & 0.2 TB \\
     1737AP db          &  24 TB \\
     1738\hline
     1739total              & 461 TB \\
    16721740\hline
    16731741\end{tabular}
    … …  
    16801748principal areas: raw image data, static sky image data, master
    16811749calibration images, the metadata database, and the object database.
    1682 We discuss each of these data items and their impact on the data
    1683 storage requirements for the IPP for PS-1.  Table~\ref{storage}
    1684 summarizes the data storage requirements in the different scenarios.
    1685 
    1686 \paragraph{Raw Data Storage}
    1687 
    1688 There are two basic image types which will be acquired: night-time
    1689 science images and calibration images.  The night-time science images
    1690 consist of 1Gpix per image, or 2GB in raw format.  At nominal cadence,
    1691 the PS-1 telescope can obtain images at a sustained rate of 1 image
    1692 per 30 seconds for the entire night of 10 hours (36000 seconds).  A
    1693 total of 100 calibration images per night would be a substantial
    1694 overestimate of the typical expectation.  Combining these numbers, we
    1695 can expect to receive a total of 1300 images, or 2.6 TB of data per
    1696 night.  The total data storage requirements for the raw data are
    1697 governed by the number of nights' worth of data we are required to
    1698 keep online.  \tbd{for the first year, we are required to keep all
    1699 images from the AP and IPV surveys.  This amounts to a total of 200
    1700 TB of data}.
    1701 
    1702 \paragraph{Static Sky Data Storage}
    1703 
    1704 The static sky is represented by images with 0.2 arcsec per pixel.
    1705 There will be one summed image and one weight image for each of the
    1706 \tbd{6} filters, each stored with 16 bits of resolution, for a total
    1707 of 24 bytes per sky pixel.  At this resolution, there are 324 Mpix per
    1708 square degree, and we will observe a potential total area of 30,000
    1709 square degrees.  Allowing for 10\% overage for overlapping tiling, we
    1710 require a total of 10.7 Tpix to cover the sky once, or a total of
    1711 $\sim 256$ TB to maintain a single image of the static sky in all 6
    1712 filters.
    1713 
    1714 \paragraph{Calibration Frame Storage}
    1715 
    1716 The possible required calibration frames consist of the bias, dark,
    1717 and mask images, along with one flat, one flat-correction, and
    1718 multiple sky/fringe library frames per filter.  In fact, not all types
    1719 are needed at all stages.  It is very likely that we will not require
    1720 bias or dark images, and mask images may be represented by a single
    1721 byte per pixel.  Nonetheless, it is necessary for us to generate and
    1722 store all master calibration frames at least until we prove that they
    1723 are not needed.  We assume a total of 21 calibration images are
    1724 necessary (one flat, fringe, and sky per filter, along with a bias,
    1725 dark, and mask).  If we intend to keep all master calibration frames
    1726 for the project lifetime, and generate a new master on a weekly basis
    1727 (a reasonable time-scale), then we can expect to require a total of 5
    1728 TB of calibration image by the end of the 2 years of PS-1.  We note
    1729 that this is likely to be a drastic overestimate as we are unlikely to
    1730 need to regenerate all master calibration frames on a weekly
    1731 time-scale.
    1732 
    1733 \paragraph{Metadata Database Storage}
    1734 
    1735 The metadata data storage requirements are driven by the need to store
    1736 the data for the project lifetime.  There are two types of metadata
    1737 generated at the summit: data associated with images and environmental
    1738 data.  The environmental data consists of measurements on a regular
    1739 cadence, roughly 1 per minute, of a variety of parameters.  We suggest
    1740 an expected of 1kB per entry, for a total of 1 GB over the two-year
    1741 term of PS-1.  The additional systems, such as the DIMM, SkyProbe, NIR
    1742 Sky Camera, and the LRProbe will have higher data requirements, but
    1743 should be considered as separate, self-contained systems.  Their data
    1744 products are distilled to a limited number of parameters per minute
    1745 which are included in the 1kB given above.  Furthermore, items such as
    1746 guide-star history, if saved, will be saved with the image data and
    1747 represents only a small fraction of the total image data volume.  Some
    1748 subset of the telescope diagnosic information may be a high volume
    1749 data product as well, but only retained by the telescope control
    1750 system for the purpose of diagnostic studies.  Such data will be
    1751 excluded from this analysis.
    1752 
    1753 The image metadata consists of values associated with the FPA (1), the
    1754 OTAs (64), and the Cells (4096).  Aside from the guide star history,
    1755 the total data requirements for each of these entries will be scaled
    1756 by the number of bytes required for the metadata from each data level.
    1757 Clearly, if the Cell entry is allowed to be large, it will dominate
    1758 the total Metadata data volume.  We suggest an expected number of 64
    1759 bytes per Cell, 256 B per OTA, and 1k per FPA, yielding a total
    1760 metadata volume per exposure of roughly 0.3 MB, completely dominated
    1761 by the Cell metadata.  With the exposure rates above, we find a total
    1762 of metadata volume of 0.3 TB over the two-year term of PS-1.
    1763 
    1764 \paragraph{Object Database Storage}
    1765 
    1766 The hardware requirements for the IPP object database are rather
    1767 flexible: the total volume depends critically on the depth to which
    1768 the object detection analyses are performed (and thus the total number
    1769 of object detections) and the number of object parameters which are
    1770 measured.  We can make very rough estimates that the total number of
    1771 detections over the 2 year lifetime of the project may be in the
    1772 vicinity of $10^{11}$.  We can conservatively estimate the number of
    1773 bytes needed to represent each detection as 128 B, resulting in a
    1774 total data storage for the object detections of 12 TB.  However, this
    1775 number depends strongly on the timescale for which the IPP is required
    1776 to maintain all object detections, and may potentially be
    1777 significantly reduced.
     1750Table~\ref{storage} summarizes the data storage requirements for these
     1751types of data. 
     1752
     1753The IPP must store all raw images from the first year from the AP and
     1754IVP surveys.  This corresponds to 175,000 images, or 175 TB, assuming
     17551 GB per image and compression.  The IPP will require space for 200 TB
     1756of raw imagery to store the data from these two survey components
     1757along with raw calibration, test, and other raw images not in the AP
     1758and IVP surveys.
     1759
     1760The IPP must store a single copy of the complete static sky in all
     1761four filters.  With the assumed image sampling of 0.2 arcsec per
     1762pixel, this corresponds to 9.7 Tpix per filter, or a total of 235 TB
     1763for the 6 filters, with 2 bytes for the noise map and 2 bytes for the
     1764image map. 
     1765
     1766The IPP must also store other, smaller collections of data.  The other
     1767components contribute only a small fraction of the data storage
     1768requirement.  The metadata is a fraction of a terabyte, while the
     1769calibration frames (all master detrend frames) represent at most a few
     1770terabytes.  The AP object and detection data make up a total of 24
     1771terabytes (see Table~\ref{APrates}). 
     1772
     1773The IPP must have storage capacity for a total of 461 TB of data.
    17781774
    17791775\subsubsection{CPU Requirements}
    17801776
    1781 Phase 2 and Phase 4 dominate the processing requirement, primarily
    1782 because they must keep up with the image delivery rate of 1 per 30
    1783 seconds.  We have performed benchmarks of a demonstration version for
    1784 both the Phase 2 and Phase 4 analyses.
    1785 
    1786 For the Phase 2, a substantial fraction of the processing time is
    1787 consumed by the need to perform FFTs on the images in order to
    1788 convolve them with the guide-star kernel, and in the smoothing used
    1789 for the object detection process.  Additional processing time is
    1790 needed by the object detection, deblending, and analysis.  Experiments
    1791 with the FFTW package show that FFTs may be performed on Intel
    1792 processors at rates of approximately 0.25 GHz-sec / Mpix for data sets
    1793 of order 1 Megapixel.  The FFTs required for the Phase 2 analysis are
    1794 performed on the 512$^2$ pixel cells, so these numbers may roughly be
    1795 scaled linearly to determine the total time required for OTA
    1796 processing.  A single FFT on a full OTA, with 64 Cells, therefore
    1797 requires roughly 4 GHz-sec.  For the full Phase 2 analysis, there are
    1798 roughly 4 single direction FFTs required excluding those associated
    1799 with object detection; thus the total processing time for these FFTs
    1800 is approximately 16 GHz-sec.  The addtional analysis steps, excluding
    1801 object detection and characterization, account for a small fraction of
    1802 this compute time, which we estimate at 10\%.  The object detection
    1803 stage depends somewhat on the depth to which the analysis is
    1804 performed, and the number of measurements made per object.  Typical
    1805 analysis performed by the Sextractor routine, which performs a
    1806 substantial number of per-object analyses, requires 27 GHz-sec for a
    1807 full OTA, including the FFTs used for smoothing.  We can therefore
    1808 assume a total of 50 GHz-sec per OTA for the Phase 2 processing.  This
    1809 converts to a total of 12800 GHz-sec for a complete major frame.
    1810 
    1811 For Phase 4, the main computational tasks are combining the multiple
    1812 images, with cosmic-ray rejection, and performing the object detection
    1813 tasks.  Nick Kaiser has done tests of the Phase 4 image combine and
    1814 rejection stages, and finds a total processing time of roughly 96
    1815 GHz-sec for a full stack of 4 OTA images.  If we add in an additional
    1816 34 GHz-sec for detailed object detection and image differencing, we
    1817 find a conservative estimage of 130 GHz-sec for a 4-image OTA stack,
    1818 equivalent to 7800 GHz-sec for a major frame.
    1819 
    1820 For PS-1, the typical time for a major frame is $4 \times 30$ seconds.
    1821 Some reduction in the load may be gained by reducing the complexity
    1822 and depth of analysis for PS-1.  Depending on the details and depth of
    1823 the analysis, we may reduce the computational load by a factor of 2.
    1824 
    1825 \begin{table}
    1826 \begin{center}
    1827 \caption{Data I/O (MB per OTA or Sky-cell) \label{scenarios}}
    1828 \begin{tabular}{lr}
    1829 \hline
    1830 \hline
    1831 {\em Phase 2 input}                                \\
    1832 from summit    &                 $2 \times 32$ MB  \\
    1833 input image    &                       {\bf 32 MB} \\
    1834 calibration    &            {\bf 4 $\times$ 32 MB} \\
    1835 mask image     &                       {\bf  8 MB} \\
    1836 \hline
    1837 network I/O:   &                            64 MB  \\
    1838 disk I/O:      &                           176 MB  \\
    1839                &                                   \\
    1840 {\em Phase 2 output}                               \\
    1841 output image   &                      {\bf  32 MB} \\
    1842 output mask    &                      {\bf   8 MB} \\
    1843 image to P4    &               $1.5 \times 32$ MB  \\
    1844 mask to P4     &               $1.5 \times  8$ MB  \\
    1845 \hline
    1846 network I/O:   &                            60 MB  \\
    1847 disk I/O:      &                            40 MB  \\
    1848                &                                   \\
    1849 {\em Phase 4}  &                                   \\
    1850 input images   &      $1.5 \times 4 \times 32$ MB  \\
    1851 input masks    &      $1.5 \times 4 \times  8$ MB  \\
    1852 static sky     &                            32x9/4 MB  \\
    1853 static weight  &                            32x9/4 MB  \\
    1854 \hline
    1855 input:         &                           304 MB  \\
    1856 output:        &                            96 MB  \\
    1857 \hline
    1858 \multicolumn{2}{l}{\em Bold-faced entries are access to local-disk} \\
    1859 \multicolumn{2}{l}{\em parenthesised disk I/O numbers are parallel with the network I/O} \\
    1860 \end{tabular}
    1861 \end{center}
    1862 \end{table}
     1777The IPP must provide sufficient computing resources to keep up with
     1778the data analysis tasks.  The minimal processing requirement is that
     1779the analysis of a typical night's worth of data be completed within 12
     1780hours of the start of the night.  With a typical night length of 8
     1781hours, and a maximum read rate of 1 image every 30 seconds, this
     1782implies an average of 45 seconds per image.
     1783
     1784The science image analysis dominates the processing requirements.
     1785Within the science image analysis, Phase 2 and Phase 4 dominate the
     1786processing requirements.  These two phases are performed in sequence
     1787with separate computers performing the analyses.  They may therefore
     1788be addressed independently. 
     1789
     1790The IPP must perform the Phase 2 analysis within an average time of 45
     1791seconds per single Gigapixel camera image.  The Phase 2 analysis has
     1792been measured to require 3200 GHz-sec on a x86/32 bit machine,
     1793implying a requirement of NN GHz for the Phase 2 analysis, if NN sec
     1794are devoted to I/O.
     1795
     1796The IPP must perform the Phase 4 analysis on a set of 4 input frames
     1797within an average time of 180 seconds.  The Phase 4 analysis has been
     1798measured to require a total of 7800 GHz-sec on an x86/32 bit machine
     1799for a major frame of 4 input Gigapixel camera images. 
     1800
     1801\subsubsection{Network I/O Requirements}
     1802
     1803The switch I/O requirements are defined by the total number of bytes
     1804per second serviced by the network switch.  In the assumption that all
     1805Phase 2 processing is performed locally on the nodes which store the
     1806raw images and the corresponding detrend images, and that all Phase 4
     1807processing requires complete network distribution of both the initial
     1808and updated static sky images, the total I/O for a 180 second
     1809major-frame period is:
     1810\begin{itemize}
     1811\item 8 GB from summit to Phase 2 (4 images @ 2 GB each)
     1812\item 18 GB from Phase 2 to Phase 4 (3 bytes per pixel for image +
     1813  mask, 50\% image overhead)
     1814\item 9 GB from Static Sky to Phase 4 (2.25 static-sky pixels per
     1815  input image pixel, 4 bytes per pixel).
     1816\item 9 GB from Phase 4 to Static Sky
     1817\end{itemize}
     1818for a grand total of 44 GB over 180 seconds, or 244 MB/second, of
     1819which 26 GB are processed by the Phase 2 nodes and 36 are processed by
     1820the Phase 4 nodes.  The IPP must be capable of sustaining this network
     1821load.
     1822
     1823\paragraph{Disk I/O Requirements}
     1824
     1825The disk I/O requirements are determined by the total number of bytes
     1826read from and written to disk. For each major frame processed, the
     1827total I/O to and from disk for Phase 2 is:
     1828\begin{itemize}
     1829\item 8 GB raw image from summit to Phase 2 nodes (4 images @ 2 GB each)
     1830\item 8 GB raw image from Phase 2 disk to memory
     1831\item 40 GB detrend image from Phase 2 disk to memory
     1832\item 12 GB processed image from memory to Phase 2 disk (2 bytes image
     1833  + 1 byte mask).
     1834\item 18 GB processed image from Phase 2 disk to Phase 4
     1835\end{itemize}
     1836for a grand total of 86 GB I/O for Phase 2.  Equivalently, for each
     1837major frame processed, the total I/O to and from disk for Phase 4 is:
     1838\begin{itemize}
     1839\item 18 GB processed image from Phase 2 disk to Phase 4
     1840\item  9 GB static image from Phase 4 disk to memory
     1841\item  9 GB static image from memory to Phase 4 disk
     1842\end{itemize}
     1843for a total of 36 GB I/O for Phase 4. 
    18631844
    18641845\subsubsection{Per-Node I/O Requirements}
    18651846
    18661847Data I/O per node is defined as the number of bytes per second passed
    1867 through the node's network adapter.  The data throughput for each node
    1868 depends strongly on the how the data is organized and processed.  In
    1869 this section, we identify the data which is passed between nodes for
    1870 the two stages of the science analysis process.  Table~\ref{scenarios}
    1871 lists the per-node data I/O for the analysis stages.
    1872 
    1873 For PS-1, there are 120 seconds of compute time allowed for each of
    1874 the Phase 2 and Phase 4 analyses for the collection of four images
    1875 which makes up a cannonical major frame.  We use the data I/O volumes
    1876 and some assumptions about expected network and disk bandwidth to
    1877 estimate the I/O and processing timeline for the four scenarios. From
    1878 this analysis, we can judge the total CPU requirements in terms of
    1879 GHz, not just GHz-sec.  We have assumed that GigE network adapters are
    1880 capable of delivering data at 50MB/sec sustained and that a disk RAID
    1881 can deliver sustained 100 MB/sec reads and writes.  These numbers are
    1882 conservative estimates based on recent tests discussed below.  Using
    1883 these assumptions, Table~\ref{throughput} lists the time allocations
    1884 for the processing stages.
    1885 
    1886 \paragraph{Phase 2 Node I/O Requirements}
    1887 
    1888 In the assumed data distribution scenario, there is a single CPU
    1889 allocated to each OTA in the OTA farm and a single CPU for each Sky
    1890 cell process.  In addition, all data for the specified OTA are stored
    1891 on local disks attached to the same computer as the CPU, with the
    1892 result that all Phase 2 I/O is made to a local disk.  For each science
    1893 OTA image which is observed, each OTA node will read from the network
    1894 a total of 2 raw images (one for the original image, one for a backup
    1895 copy) and write an average of roughly 1.5 processed images and masks
    1896 to the Phase 4 machines for a total of 124 MB of network I/O.  During
    1897 the processing stage, the OTA node will read from disk a total of 176
    1898 MB (4 calibration frames at 32 MB each, one 16 MB mask, and one raw
    1899 science image at 32 MB) and write a total of 40 MB (one processed
    1900 image at 32 MB and one mask at 8 MB).  Given the assumptions for the
    1901 network and disk bandwidths (50 MB/s and 100 MB/s respectively), the
    1902 data volumes imply a total I/O period of 4.6 seconds.  In this
    1903 instance, the network I/O is presumed to be sequential with the disk
    1904 I/O.
    1905 
    1906 \paragraph{Phase 4 Node I/O Requirements}
    1907 
    1908 Although it is easy to arrange the OTA data in such a way that the
    1909 majority of I/O is performed locally, it is not as easy to arrange
    1910 this for the Static Sky data used by the Phase 4 analysis.  We
    1911 therefore make the assumption that the Phase 4 analysis will require
    1912 all input OTA data to be loaded across the network, as well as all
    1913 Static Sky data.  This is somewhat of an overestimate as some of the
    1914 Static Sky data will be processed by machines with the data stored
    1915 locally, and clever Static-Sky data organization schemes can enhance
    1916 this chance. 
    1917 
    1918 In the Phase 4 analysis, the images from the 4 separate telescopes are
    1919 combined into a single image, confronted with the appropriate segment
    1920 of the static sky, with output difference image and updated static sky
    1921 image.  If we restrict input access to the individual OTA cells, the
    1922 maximum read overhead is 50\% (need to read a 10x10 set of cells for
    1923 an 8x8 input image).  If the processing is performed on Static Sky
    1924 segments equivalent in size to the OTAs, the total volume of input
    1925 data per node is 304 MB (192 MB of processed science image, 48 MB of
    1926 input mask, 32 MB of static sky image and 32 MB of static sky weight
    1927 map) while the output data is 96 MB (32 MB static sky, 32 MB weight
    1928 map, and 32 MB difference image).  Thus, we require a total of 400 MB
    1929 network I/O, which implies an I/O period of 8 seconds.
    1930 
    1931 \begin{table}
    1932 \begin{center}
    1933 \caption{Data Throughput \label{throughput}}
    1934 \begin{tabular}{lr}
    1935 \hline
    1936 \hline
    1937 Phase 2 per-node network I/O       & 2.2 s           \\
    1938 Phase 2 per-node disk I/O (read)   & 1.3 s           \\
    1939 Phase 2 per-node disk I/O (write)  & 1.2 s           \\       
    1940 Phase 2 CPU total                  &  25 s : 128 GHz \\
    1941 Phase 4 per-node I/O               &   8 s           \\
    1942 Phase 4 CPU total                  & 112 s : 70 GHz  \\
    1943 Phase 2 switch load                & 264 MB/s \\
    1944 Phase 4 switch load                & 215 MB/s \\
    1945 Phase 2 to Phase 4 switch load     & 160 MB/s \\
    1946 Summit to Phase 2 switch load      &  70 MB/s \\
    1947 \hline
    1948 \end{tabular}
    1949 \end{center}
    1950 \end{table}
    1951 
    1952 \subsubsection{Switch I/O Requirements}
    1953 
    1954 The switch I/O requirements are defined by the total number of bytes
    1955 per second serviced by the two switches in the system. 
    1956 
    1957 The Phase 2 network I/O is 124 MB per OTA.  With 64 OTAs per image,
    1958 and 30 seconds average between images, this implies a total of 264
    1959 MB/s switch bandwidth.  The Phase 4 network I/O is 400 MB per sky
    1960 cell.  With 64 cells and 120 seconds between major frames, this is an
    1961 average switch bandwidth of 215 MB/s switch bandwidth.  The total
    1962 switch-to-switch load is 304 MB per OTA, with an average timescale of
    1963 120 seconds.  With 64 OTAs, this corresponds to 160 MB/s.  The
    1964 summit-to-Phase 2 switch load is 70 MB/s.
     1848through the node's network adapter.  The data I/O per node is tied to
     1849the total processing power and the total number of nodes.  A useful
     1850way to examine the per-node I/O requirements is to compare the I/O and
     1851CPU requirements to determine the required number of processing nodes.
     1852The assumption is made that each CPU is associated with a single disk
     1853RAID which may deliver data at a rate of 100 MB/sec and a GigE
     1854ethernet controller which may deliver data at a sustained rate of 50
     1855MB/sec, and that each CPU is equivalent to 4 GHz.  The IPP must
     1856therefore have a total of 26 Phase 2 nodes and 16 Phase 4 nodes. 
    19651857
    19661858%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    … …  
    20051897
    20061898See Appendix A \& B of the IPP Library SDR (PSDC-430-007) for the test
    2007 verification matricies for the Pan-STARRS IPP Library
     1899verification matrices for the Pan-STARRS IPP Library
    20081900
    20091901%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Note: See TracChangeset for help on using the changeset viewer.