Index: trunk/doc/pslib/.cvsignore =================================================================== --- trunk/doc/pslib/.cvsignore (revision 2194) +++ trunk/doc/pslib/.cvsignore (revision 2237) @@ -1,2 +1,5 @@ -*.log *.dvi *.aux *.toc *.log *.out *.lof +*.log *.dvi *.aux *.toc *.log *.out *.lof *.tbr *.tbd psLibADD.pdf psLibSDRS.pdf psLibSRS.pdf +old +notes +.mana Index: trunk/doc/pslib/psLibSRS.tex =================================================================== --- trunk/doc/pslib/psLibSRS.tex (revision 2194) +++ (revision ) @@ -1,321 +1,0 @@ -%%% $Id: psLibSRS.tex,v 1.7 2004-08-06 19:06:36 eugene Exp $ -\documentclass[panstarrs]{panstarrs} - -% basic document variables -\title{Pan-STARRS Image Processing Pipeline} -\subtitle{Software Requirements Specification} -\author{Eugene Magnier} -\shorttitle{IPP SRS} -\group{Pan-STARRS Algorithm Group} -\project{Pan-STARRS Image Processing Pipeline} -\organization{Institute for Astronomy} -\version{00} -\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 -PSDC-430-xxx & PS-1 Design Reference Mission \\ \hline -PSDC-430-004 & Pan-STARRS IPP C Code Conventions \\ \hline -PSDC-430-006 & Pan-STARRS IPP ADD \\ \hline -PSDC-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} - -\tbd{deferred} - -\subsection{System Capability Requirements} - -\subsubsection{Software Coding Requirements} - -\paragraph{Languages} - -Source code must be in C. All source code must be compiled with -`gcc' version v2.95 or higher. - -Scripting language must be in \tbd{Perl, version TBD}. - -\paragraph{Interfaces} - -Access to low-level Library functions must be provided via C APIs -consisting of the function calls and the defined data structures and -other data types. Access to high-level functions must be provided -via C APIs as well as SWIG interfaces, where specified. Access to -processing jobs must be available via the UNIX shell. - -\paragraph{Coding Standards} - -The C code must comply with ANSI Standard C99. Because the delivered -code is required to run on UNIX machines, the delivered code must 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 must use the UNIX line-break -convention (line-feed only). C coding style must adhere to the -standard defined in the document 'Pan-STARRS C-coding standard' -(PSDC-430-004). \tbd{Perl coding must follow the Perl standard -defined in the document TBD}. - -\paragraph{Naming Conventions} - -Header files must have names starting \code{ps} or \code{p_ps} for -private interface definitions. The latter must appear in a -subdirectory \code{private} of whichever directory is being searched -for the public header files. - -Functions visible at global scope which are part of the public API -must have names begining with \code{ps}, and follow the naming -conventions in the coding standard. Functions that are visible at -global scope but which are not part of the public interface must have -names begining with \code{p_ps}. Functions that are local to a file -must \textit{not} start \code{ps} (or \code{p_ps}). - -Variables visible at global scope which are part of the public API -must have names begining with \code{ps}, and follow the naming -conventions in the coding standard. Variables that are visible at -global scope but which are not part of the public interface must have -names begining with \code{p_ps}. Variables that are local to a file -must \textit{not} start \code{ps} (or \code{p_ps}). - -The names of all enumerated types and C-preprocessor symbols (but not -variables declared \code{const}) must start with \code{PS_}, in the -case of public symbols, or \code{P_PS_}, for private symbols. The -rest of the name must be uppercase with words separated by underscores -(\code{_}). An exception is the case of system utilities implemented -as macros, in which case the names must conform to the convention for -function names. - -When defining a function to convert from one type to another, the name -should be of the form \code{psOldToAlloc}, e.g.\hfil\break -\code{psEquatorialToEcliptic} (\emph{not} -\code{psEquatorial2Ecliptic}). - -\paragraph{C Programming Guidelines} - -Functions that assign to a variable should list that argument -\textit{first}, following the pattern of \code{strcpy}; e.g. -\begin{verbatim} -void psAddToVector(restrict psVec *outVec, const restrict psVec *inVec, - int val); -\end{verbatim} - -Type definitions should always be accompanied by prototypes for their -constructors and destructors, following these guidelines: - -\begin{itemize} -\item The constructor name should consist of the type name followed by -\code{Alloc}; e.g. a type \code{psImage} would be created by a -function -\begin{verbatim} -psImage *psImageAlloc(int nrow, int ncol); -\end{verbatim} - -\item The type should be freed with a destructor named \code{typeFree}, e.g. -\begin{verbatim} -void psImageFree(psImage *img); -\end{verbatim} - -\item The constructor must never return \code{NULL}, and no code calling the -constructor should ever check the return value. - -\item The destructor must not return a value. - -\item The destructor must handle being passed \code{NULL} by simply -returning immediately. This should not be treated as an error -condition. - -\item Constructors and Destructors should use the memory reference - counter facilities of the PSLib memory management system. - -\end{itemize} - -\paragraph{Commenting and Documentation} - -Commenting of delivered C and Perl code must follow the C and -Perl coding standards and must 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 must be generated with -Doxygen from the in-line comments and must 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 must be delivered as PDF documents. - -\paragraph{Version Control} - -Source code version control must be implemented with CVS. - -\paragraph{CSCI Deliverable} - -All final source code generated for the IPP is to be delivered via -CVS, including the test code. CVS revision history must be included -and made available via CVS. - -\paragraph{Platform architectures and operating systems} - -Makefiles must 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 both listed -operating systems, unit testing should only be performed for the -x86/Linux combination. - -\paragraph{Software Configuration} - -\tbd{deferred} - -\subsubsection{Architectural Components} - -\tbd{deferred} - -\subsubsection{Analysis Stages} - -\tbd{deferred} - -\subsubsection{Modules} - -\tbd{deferred} - -\subsubsection{Pan-STARRS 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} - -\tbd{deferred} - -\subsection{External Interfaces} - -\tbd{deferred} - -\subsection{Internal Interfaces} - -\tbd{deferred} - -\subsection{Internal Data Requirements} - -\tbd{deferred} - -\subsection{Computer Hardware} - -\tbd{deferred} - -\section{Test Verification} - -A testing regime must be implemented to demonstrate the working state -of the provided software. Certain tests as specified must 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 must 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 must test the integrity of the software, specifically to check -that the code does not produce memory leaks, segmentation faults. - -\subsection{Basic Unit Tests} - -MHPCC must 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 must 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 - -\bibliographystyle{plain} -\bibliography{panstarrs} -\end{document} -