Index: /trunk/doc/Makefile
===================================================================
--- /trunk/doc/Makefile	(revision 4899)
+++ /trunk/doc/Makefile	(revision 4900)
@@ -9,2 +9,5 @@
 	@rm -f *~ #*
 	for i in $(DIR); do (cd $$i; make clean); done
+
+psdc:
+	rsync -e ssh -auv PSDC-4xx/ poiserver0:doc/panstarrs/www/src/project/PSDC/PSDC-4xx/
Index: /trunk/doc/design/psched-tasks.txt
===================================================================
--- /trunk/doc/design/psched-tasks.txt	(revision 4899)
+++ /trunk/doc/design/psched-tasks.txt	(revision 4900)
@@ -1,4 +1,20 @@
-
-
+\documentclass[panstarrs,spec]{panstarrs}
+
+\title{PStask \& Metadata DB interactions} % put in your title
+\subtitle{Job Flow in IPP}
+\author{Eugene Magnier}
+\audience{IPP}
+%\shorttitle{PSPhot}
+\group{Pan-STARRS IPP}
+\project{Pan-STARRS IPP}
+\organization{Institute for Astronomy}
+\version{DR}
+\docnumber{PSDC-xxx-xxx}
+
+\newcommand\ugriz{$u^\prime g^\prime r^\prime i^\prime z^\prime$}
+\newcommand\grizy{$g r i z y$}
+
+\begin{document}
+\maketitle
 
 This collection of diagrams shows the IPP tasks and the MDDB tables
Index: /trunk/doc/ipptools/pstask.tex
===================================================================
--- /trunk/doc/ipptools/pstask.tex	(revision 4900)
+++ /trunk/doc/ipptools/pstask.tex	(revision 4900)
@@ -0,0 +1,510 @@
+\documentclass[panstarrs,spec]{panstarrs}
+
+\title{PStask \& Metadata DB interactions} % put in your title
+\subtitle{Job Flow in IPP}
+\author{Eugene Magnier}
+\audience{IPP}
+%\shorttitle{PSPhot}
+\group{Pan-STARRS IPP}
+\project{Pan-STARRS IPP}
+\organization{Institute for Astronomy}
+\version{DR}
+\docnumber{PSDC-xxx-xxx}
+
+\newcommand\ugriz{$u^\prime g^\prime r^\prime i^\prime z^\prime$}
+\newcommand\grizy{$g r i z y$}
+
+\begin{document}
+\maketitle
+
+\section{Overview}
+
+This document illustrates the interrelationships between IPP tasks and
+the Metadata Database (MDDB).  The Metadata Database is used to store
+the current IPP analysis state, as well as result processing data
+points.  The tasks needed to define each of the IPP analysis stages
+(Phase 1-4, detrend creation, etc) are illustrated in this document
+and the relevant MDDB tables are listed.  The collection of diagrams
+shows the IPP tasks and the Metadata Database (MDDB) tables needed to
+manage the flow of data through the system.
+
+\section{PStask queues and metadata tables : persistent vs ephemeral state}
+
+\begin{figure}
+\begin{center}
+\resizebox{4in}{!}{\includegraphics{pics/pstasks.01.ps}}
+\caption{\label{queues} PStask queues and MDDB tables}
+\end{center}
+\end{figure}
+
+The left-hand portion of the diagram illustrates the recommended
+interaction between the metadata database tables and the scheduler
+internal queues.  Some table in the metadata database defines a list
+of data items which are to be processed by some analysis job.  The
+scheduler uses a two-step approach to define the analysis jobs based
+on this list.  First, one scheduler task queries the MDDB for a list
+of pending items, adds the returned items to an internal scheduler
+queue.  The process of adding the elements to the queue is defined so
+that only unique items are added: already existing items are skipped.
+The entries in the queue consist of the data items of interest and an
+internal temporary state.  At first, this would be 'pending'.  A
+second scheduler tasks pops 'pending' entries one-by-one from this
+internal queue, submits a job based on the entry, and sets the
+temporary state in the internal queue to 'running'.  The internal
+state is needed to prevent the scheduler from re-submitting a job for
+the same data item before the first job is done or assessed.  Since
+the job make take an arbitrary amount of time, the scheduler requires
+a mechanism to remember which data items it has already submitted.
+When the job eventually completes, the metadata database table is
+updated noting the completion.  This may be done either by the job
+itself or by the scheduler.  In addition, the state of the entry in
+the queue can be set to either 'done' or the entry can be simply
+removed from the queue.
+
+The purpose of this interaction is to maintain the temporary state
+information within non-persistent elements of the scheduler rather
+than using the metadata database tables to store this information.
+This concept has two advantages.  First, the scheduler internal queues
+are in memory and relatively small, thus interfacing with them is
+quite fast for the scheduler -- this should reduce the system latency.
+Second, by keeping this information non-persistent, the system
+responds correctly to stopping and restarting the scheduler.  Any jobs
+which have not been completed will not be marked in the database, and
+will be restarted naturally by the scheduler.  The alternative, of
+writing a temporary state marker in the database would require a
+restarted scheduler to initially clean all database tables of these
+temporary state markers.
+
+The right-hand portion of the diagram illustrates this process using
+the process of copying the images from the summit as an example.  The
+metadata database table of interest in this case is the list of
+pending images, with entries supplied by a job which queries the
+summit data systems.  The job which is actually performed is a remote
+copy of the image file from the location specified by the summit data
+system to the appropriate location within the IPP Image Server
+(Nebulous).  (As an alternative to the above, the 'pending images'
+table may be part of the summit database system, and the 'get images'
+command may query the summit directly.  In this scenario, the 'copy
+image' command reports to the summit data system that an individual
+image file has been copied.)
+
+In the rest of this document, the use of PStask internal queues to
+manage the temporary data states is glossed over and assumed part of
+the tasks defined in the process.
+
+\section{Summit Copy Tasks}
+
+\begin{figure}
+\begin{center}
+\resizebox{4in}{!}{\includegraphics{pics/pstasks.02.ps}}
+\caption{\label{pcopy} Summit Copy Tasks}
+\end{center}
+\end{figure}
+
+This diagram illustrates the MDDB tables used to copy data (images and
+metadata tables) from the summit.  The left-hand portion of the
+diagram shows the tables involved in copying images from the summit
+system.  The table of pending image files lists the URLs of the
+individual image files available for transfer, along with their
+associated exposure ID and the camera which generated the image.  Two
+other entries assist in interpreting the file: the class and the class
+ID.  The final entry in this table is the current copy state of the
+file, can have the value of 'ready' or 'copied'.
+
+The class defines the data grouping represented by this image file and
+may have values of: FPA, Chip, Cell.  This value indicates that the
+provided image file represents the specified portion of the camera
+FPA.  If the value is FPA, the file represents data from a complete
+FPA, though the file may contain pixel data in multiple extensions or
+other groupings to be identified later.  If the value is chip, the
+file contains only data for a single chip, presumably of multiple
+chips available, and equivalently for Cell.  Further discussion of the
+FPA image hierarchy is given in the IPP documents (eg, Modules SDRS).
+The class ID gives the identifier used to name the class level
+corresponding to this file.  This value is necessary to make decisions
+on how to copy the data based on the chip / cell before the data is
+available to IPP components.  Here are likely values for the class and
+class ID for some common cameras:
+
+\begin{table}
+\begin{center}
+\caption{Camera and Data Classes\label{classes}}
+\begin{tabular}{lll}
+\hline
+\hline
+camera   & class  & classID \\
+\hline
+GPC	 & chip   & chip02 \\
+skyprobe & fpa 	  & sp01 \\
+Megacam  & fpa	  & MegacamSpliced \\
+Suprime	 & chip	  & chip0 \\
+\hline
+\end{tabular}
+\end{center}
+\end{table}
+
+and so forth.  The system described is sufficiently flexible to allow
+us to transfer the GPC images by cell if we eventually decide that is
+more efficient.  
+
+The copy process copies the file from the given URL to the appropriate
+IPP node and adds an entry to the table of new image files, consisting
+of the same information as the pending image file table, though with a
+new value for the URL.  This URL may be an explicit filename, a
+reference to an entry in the image server, or a web address, or
+located on the image server (marked with file:, neb:, and http:,
+respectively).  (TBD: other possible file storage types?  perhaps the
+path could be abstracted without going to the level of the image
+server?  eg: ref:DIR0001/file0001.fits might be in a directory which
+is defined in a table of directories.) After an image file is
+successfully copied, the corresponding state in the 'pending chip'
+table is updated from 'ready' to 'copied'.
+
+The right hand portion of this diagram illustrates the process of
+copying a metadata table.  The table of pending tables lists the URLs
+for the tables which are ready, a unique table ID for each table, and
+the table type.  The copy function copies the listed table and uploads
+the data to the IPP version of the same metadata database.  Two
+examples of metadata tables needed by the IPP for the basic image
+processing system are illustrated: the table of new exposures and the
+table of pending matches.  The first lists the exposures which are
+avilable from the summit system, and all represent entries which are
+available from the Image server.  the second represents the matches
+between exposure IDs and chips
+
+\section{Phase 0}
+
+\begin{figure}
+\begin{center}
+\resizebox{4in}{!}{\includegraphics{pics/pstasks.03.ps}}
+\caption{\label{phase0} Phase 0 Tasks}
+\end{center}
+\end{figure}
+
+This diagram illustrates phase 0, in which the image files are
+categorised, examined for summary information and basic statistics,
+and moved to the tables used to trigger further analysis.  The process
+first examines the 'new image files' table.  It selects images from
+this table which have not yet been examined (state is 'new').  The
+file header is examined and relevant metadata is extracted (eg, RA,
+DEC, times, and so forth to be defined later).  The process may also
+select a portion of the image pixel data to determine a rough bias and
+background level.  These statistics, whether derived from the header
+or the pixel values, are placed along with image summary information
+in the 'raw image files' table, and the state field of the 'new image
+files' table is set to 'ready'.  
+
+The process is also responsible for moving the exposures to the tables
+used for triggering the analysis process.  If the image class is FPA,
+the image can be advanced without waiting for any other image files.
+If the class is Chip or Cell, the process must also examine the 'new
+exposure' table for this exposure ID.  The number of class files
+available for this exposure is listed in this table.  The process must
+the select all image files matching the exposure ID with state of
+'ready' and compare the number avalable to the number expected.  If
+the two match, then a new exposure is ready.  Based on the image type
+(from the most recently examined image file header or new exp table?),
+the exposure is added to the 'raw exposure' table for images of that
+type.  The allowed types are 'detrend', (all bias, dark, flat images),
+'object', 'focus'(??), etc.  (** The different tables represent
+different analysis modes.  This process also adds an entry to the exp
+ID / image file match **).  This process also adds all science
+(OBJECT) exposures to the P1 exposure table (for mosaic data) or the
+P2 chip table (for single detector data).  These tables are used to
+trigger the Phase 1 and Phase 2 analysis stages.
+
+\section{Phase 1}
+
+\begin{figure}
+\begin{center}
+\resizebox{4in}{!}{\includegraphics{pics/pstasks.04.ps}}
+\caption{\label{phase1} Phase 1 Tasks}
+\end{center}
+\end{figure}
+
+This diagram shows the tables involved in running the P1 analysis
+stage.  There are paths for exposures to enter the analysis
+automatically from the P0 analysis (arrow on left) or to be added
+manually based on a selection from the raw exposure table.  Exposures
+to be analysed by Phase 1 are added to the P1 exposure table with the
+state 'new'.  Exposures may be added multiple times for processing and
+reprocessing. The P1 exp table keeps a record of the old attempts for
+debugging and analysis.  Each time an exposure is added to the P1 exp
+table, it is given a new, unique version number, allowing the system
+as a whole to track different analysis attempts.  This method is used
+in all of the image analysis stages (and extrapolated to iterations in
+the detrend analysis steps below).  The top portion of the diagram
+represents the user-space tool which may be used to re-submit an
+exposure or a group of exposures, potentially selected on the basis of
+a query from the raw SCIENCE exposure table.
+
+The P1 exposure table is examined to select the new exposures, these
+are then used to generate the P1 analysis jobs.  Within the analysis
+job, the chips (image files) associated with the exposure are select
+from the raw image file table.  The analysis examines the contents of
+these files, either extract the guide star information from the image
+files (GS table extension) or searches for and centroids the pixels on
+appropriate bright stars.  The analysis results in astrometric
+calibration terms which are written to the astrometric calibration
+file for this exposure.  The location of the astrometric calibration
+file and the statistics of the measurement are written back to the P1
+exposure table.  The images associated with exposures which are
+successfully processed by P1 are then added to the P2 image table,
+which is used to trigger the Phase 2 analysis.
+
+\section{Phase 2}
+
+\begin{figure}
+\begin{center}
+\resizebox{4in}{!}{\includegraphics{pics/pstasks.05.ps}}
+\caption{\label{phase2} Phase 2 Tasks}
+\end{center}
+\end{figure}
+
+This diagram shows the tables involved in running the P2 analysis
+stage.  There are paths for images to enter the analysis automatically
+from the P1 analysis (arrow on left) or to be added manually based on
+a selection from the raw exposure and raw image file tables.  Images
+to be analysed by Phase 2 are added to the P2 image table with the
+state 'new'.  When images are added to this table, a single entry is
+also added to the P2 exposure table listing the P1 and P2 versions for
+this exposure.  These version numbers must be integers starting with
+1.  If this image did not have a P1 analysis, the P1 version is set to
+0.  Exposures may be added multiple times for processing and
+reprocessing. The P2 image table keeps a record of the old attempts
+for debugging and analysis.  As with P1, each time a collection of
+associated images from an exposure is added to the P2 image table, it
+is given a new, unique version number, allowing the system as a whole
+to track different analysis attempts.  The top portion of the diagram
+represents the user-space tool which may be used to re-submit the
+images for an exposure or a group of exposures, potentially selected
+on the basis of a query from the raw SCIENCE exposure and raw image
+file tables.
+
+The P2 image table is examined to select the 'new' images.  These
+images are used to generate P2 analysis jobs.  The P2 analysis uses
+the input url to find and load the image file.  The url may be a file
+on disk, an entry in the image server, Nebulous, etc.  The master
+detrend images matching the specific science image and the conditions
+are selected by examining the table of master detrend frames.  The
+specific detrend image files are selected by using the master detrend
+ID to select the matching the entries in the table of master detrend
+files.  After the analysis, the output image, mask, and FITS table of
+objects, including the astrometry calibration, are written to the P2
+image table, along with summary statistics from the P2 analysis.  The
+state is also updated (to 'done').  
+
+Whenever the exposure is completed, the value of Ndone in the P2
+exposure table is incremented.  If all P2 images matching the P2
+exposure version have been completed, the value of Ndone will match
+Nclass, and in this case, the process adds an entry to the P3 exposure
+table.
+
+\section{Phase 3}
+
+\begin{figure}
+\begin{center}
+\resizebox{4in}{!}{\includegraphics{pics/pstasks.06.ps}}
+\caption{\label{phase3} Phase 3 Tasks}
+\end{center}
+\end{figure}
+
+This diagram illustrates the tables involved in the Phase 3 analysis.
+The P3 exposure table lists the exposure ID, the P3 analysis version,
+the P2 analysis version to be used as input to this P3 analysis, and
+the recipe to be used.  The P2 exposure and image tables are used, in
+conjunction with the P2 version information, to select the P2 output
+measured objects and the astrometric calibrations from P2 and P1.
+These measured objects are matched with the reference catalog objects,
+and calibrated astrometry and photometry is produced for the full
+exposure.  The location of the resulting astometry calibration table
+is stored back in the P3 exposure table.  If the recipe file
+specifies, the 2-D photometric and background / fringe corrections may
+also be performed at this stage.  Since these analyses require
+reference data, the recipe may also be used to skip these analysis if
+such reference data is unavailable or unreliable.  At the end of Phase
+3, the objects from the exposure are inserted into the photometry
+database (this is not shown). 
+
+The astrometric calibration portion of Phase 3 is principally needed
+for a mosaic camera.  For single-chip cameras, Phase 3 may be used to
+perform the photometric calibration and simply pass the astrometric
+results along to the output file to be listed in the P3 exposure
+table.  In this way, later stages of the analysis (ie, Phase 4) can
+use the P3 exposure table as input for all cameras, even if all the
+funcionality of Phase 3 is not necessary for that camera.  This would
+be the case for the skyprobe camera, for example.
+
+\section{Phase 4}
+
+\begin{figure}
+\begin{center}
+%\resizebox{4in}{!}{\includegraphics{pics/pstasks.03.ps}}
+\caption{\label{phase4} Phase 4 Tasks}
+\end{center}
+\end{figure}
+
+At the end of Phase 3, the images are ready for Phase 4.  The Phase 3
+diagram shows the output line adding the exposures to be processed by
+Phase 4 to a Phase 4 table.  However, this line is just for
+illustration purposes.  The rules for initiating a Phase 4 run are
+somewhat more complicated than those for running Phases 1-3.  Groups
+of exposures which have an appropriate overlap should be chosen for
+the Phase 4 analysis.  In the steady-state period of PS-4, it may be
+straightforward to choose the exposure groups: they would simply be
+the exposures obtained nearly simultaneously by the four separate
+cameras.  The circumstance for PS-1 will be much more complicated (and
+even PS-4 will probably be more complex than it seems at first
+glance).  For example, in PS-1, we will not have a static sky for most
+of the AP Survery.  In this circumstance, we cannot run P4, at least
+until after the complete AP Reference catalog is built, and
+potentially all exposures re-run through Phase 3.  It may be useful
+for the AP Survey data to split the Phase 4 analysis into two stages:
+image combination and image differencing.  It may even be the case
+that only the combination portion of Phase 4 is performed on the AP
+Survey data.  
+
+More generally, the image groups selected for Phase 4 analysis may be
+chosen on the basis of a query of the AP Database (DVO) with some
+rules.  This may be 
+
+\section{Analysis Version and Recipes}
+
+Note that each of the stages P1-P4 refer to the processing version
+from the previous stage.  This allows the processing stage to request
+the correct version of the results from the previous stage, and makes
+it possible to run and re-run the analysis at any stage without
+deleting the earlier results.  As different analysis attempts are
+performed for a given image, the versions branch out, like the diagram
+in Figure NNN.  
+
+Also note that at every stage, the entries include a recipe
+identifier.  This is used to select the analysis recipe which should
+be used for this version.  By default, the recipe should be set to the
+current best recipe (use a default name for this?).  This feature
+allows the user to run test analyses with variations on the recipe
+without altering the analysis system.  For example, it is possible to
+use a different flat-field set by specifying alternate rules for the
+flat-field selection in a recipe file.  If it is necessary to run the
+P1-P3 analysis with the raw master flats, for example, the user simply
+defines that selection in the recipe file and submits the images of
+interest to P1 (or P2, etc), with the corresponding entry for the
+recipe.
+
+The recipe file may also be used to specify alternative analysis paths
+and desitinations.  For example, it is not necessary that all analysis
+stops with P4: the recipe file may be used to halt the analysis at P2
+or P3.  In addition, the recipe file may be used to specify an
+alternative destination for the output results.  For example, to
+generate the photometric flat-field correction frame from a collection
+of dithered images, the user may not want the photometry results in
+the main DVO database.  By using the recipe to set an alternative DVO
+database target, and by specifying the use of the raw master flat
+rather than the corrected one, the analysis of the dithered images is
+kept isolated from the other photometry database results.  The
+resulting photometry may be used to construct the new, corrected
+flat-field images, and the processing of the same images using the new
+flat-field images may be sent to the master DVO database.  
+
+\section{Basic Detrend Creation}
+
+\begin{figure}
+\begin{center}
+\resizebox{4in}{!}{\includegraphics{pics/pstasks.08.ps}}
+\caption{\label{detrend} Detrend Creation Tasks}
+\end{center}
+\end{figure}
+
+This diagram illustrates the tables needed for the generic detrend
+construction process, using the flat-field construction as an example.
+This diagram is somewhat more complex than the preceeding versions.
+In this diagram, both single jobs and multiple jobs are represented by
+the process elements (the blue ellipses).  In some cases, more that
+one task will be needed to perform the function illustrated by a
+single process task.  The complexity of this diagram is enhanced by
+the need for multiple iterations and both single chip and full mosaic
+processing.  At the moment, the distinction between mosaic and single
+chip cameras is not specifically discussed.  Finally, the triggers
+which initiate a specific detrend analysis are glossed over.
+
+The detrend analysis is initiated by choosing a type of detrend image
+to be constructed and by specifying the criteria which will be used to
+select the input raw detrend frames for the construction.  For
+example, these criteria could specify that all twilight flat images
+over a certain period of days, perhaps with restrictions on the flux
+levels or the time-from-sunset of the images.  The detrend analysis
+run is given an ID (det ID) which will also be used to identify the
+resulting master detrend frame.  
+
+Given the definition of a master detrend run, the input exposures are
+selected from the raw detrend exposure table, and written to the input
+detrend exposure table.  In the next step, the corresponding image
+files are selected from the table of raw image files.  Since there
+will be a different set of input raw images for each attempt at
+creating a master detrend image, and since any given attempt may use
+some of the same input images as any other attempt, a separate table
+of input raw images is constructed.  
+
+Each of the input raw images may be pre-processed before it may be
+used to construct the detrend frame.  For example, the input
+flat-field images should (probably) be dark- and bias-corrected before
+they are stacked.  The information about these input processed images
+is written to the input images table.  If no processing is needed,
+this step simply copies the appropriate information to the table, and
+points back to the raw image, rather than a processed version.  
+
+The input processed images are combined (stacked) to create a master
+detrend image for the particular data element defined by the image
+class (chip/cell/fpa).  At this stage, not all input images should
+necessarily be included in the stack.  If residual statistics have
+been measured for the input images (say, using a prior stack), then
+some of the input image may be excluded.  The table of residual images
+is used to guide this process.  The information describing the
+resulting master image is written to the master images table.  
+
+The statistics of the master detrend images must examined so that any
+necessary renormalizations may be performed.  For example, after
+stacking the individual flat images, the resulting stacks must be
+renomalized to account for the different ranges of input image fluxes.
+This analysis is least-squares solution in which an appropriate scale
+is determined for each input exposure and a separate gain is
+determined for each of the chips or cells in the camera.  This
+analysis can only performed after all image stacks (ie, for all chips)
+have been constructed.  The resulting information is written to the
+table of master detrend frames.  
+
+Once the master detrend is constructed, the master detrend images may
+be used to construct residual images for each of the input images.
+These residual statistics, as well as the locations of the residual
+images and other related data products (jpeg thumbnails?) are written
+to the residual image table.  Note the red arrow which by-passes the
+stack construction and merge steps and skips directly to the residual
+analysis.  In some cases, it may be useful to have the input images
+confronted with an existing detrend image, and the resulting residual
+values used to guide the rest of the process.  For example, in the
+flat-field analysis, applying an earlier flat can result in a very
+good first-pass rejection of poor input images.  The logic to make
+this leap must be part of the scheduler, since each of the individual
+blocks represent complete processing jobs.
+
+Finally, the residual statistics from the complete mosaic (all input
+images, all chips) are used to assess the quality of the newly
+constructed master detrend image, and to potentially modify the
+selection of input images.  This latter process is performed by
+marking the state of the residual images from this iteration.  The
+stacking process always examines the state information for the
+residual images from the previous iteration, if it exists, when
+constructing the master stack.  Once a master detrend frame has been
+judged of high enough quality, the state of the entry for the frame in
+the master detrend frames table is set to an appropriate value to tell
+the other routines that this image should be used as a master detrend.
+The exact choice of which master detrend frame is used for a given
+science image depends on the recipe along with information such as the
+time period used or the conditions used.
+
+Note that, although this discussion focuses on the construction of
+flat-field images, the same structure should be capable of
+constructing the biases, dark, fringes, etc.  In some cases, as noted
+above, the 'process' stage is a null operation.
+
+\end{document}
Index: /trunk/doc/psphot/psphot.tex
===================================================================
--- /trunk/doc/psphot/psphot.tex	(revision 4899)
+++ /trunk/doc/psphot/psphot.tex	(revision 4900)
@@ -51,5 +51,5 @@
 data rate.  The prototype telescope alone is expected to produce
 typically $\sim 700$ GB per night of imaging data.  These images will
-not be limited to high galactic lattitudes, so large numbers of
+not be limited to high galactic latitudes, so large numbers of
 measurable stars can be expected in much of the data.  The combination
 of the high precision goals of the astrometric and photometric
@@ -83,5 +83,5 @@
 \item Sextractor : pure aperture measurement with rudimentary
   object subtraction.  pro: fast, widely used, easy to automate.  con:
-  poor object separation in crowded regions, psf-modelling is only
+  poor object separation in crowded regions, PSF-modeling is only
   beta (psfex), what models are available?
 
@@ -89,5 +89,5 @@
   con: IRAF-based, aperture photometry.
 
-\item galfit : detailed galaxy modelling.  not a multi-object PSF
+\item galfit : detailed galaxy modeling.  not a multi-object PSF
   analysis tool.  con: does not provide a PSF model, not easily
   automated.  very detailed results in very slow processing.  only a
@@ -112,13 +112,18 @@
 Perl (or potentially Python).  
 
-\note{Discussion of the lessons learned from experience with previous
-  analysis programs.  1) Flexible PSF model: functional form should be
-  easily modified.  2) PSF variation is fundamental : PSF
-  representation should incorporate 2-D variations.  3) Speed fitting
-  with accurate parameter guesses.  3) Make good use of moment
-  information to speed analysis.  4) careful definition of PSF
-  validity tests.  5) careful analysis of aperture corrections.  6)
-  flexible non-PSF models.  7) Good code abstraction to simplify
-  modification. }
+\note{Add discussion of the lessons learned from experience with previous
+  analysis programs}
+
+\begin{itemize}
+\item Flexible PSF model: functional form should be
+  easily modified.  
+\item PSF variation is fundamental : PSF representation should incorporate 2-D variations.  
+\item Speed fitting with accurate parameter guesses.  
+\item Make good use of moment information to speed analysis.  
+\item Careful definition of PSF validity tests.  
+\item Careful analysis of aperture corrections.  
+\item Flexible non-PSF models.  
+\item Good code abstraction to simplify modification.
+\end{itemize}
 
 \section{Description of the PSPhot analysis steps}
@@ -189,15 +194,15 @@
 
 The noise image, if not supplied is constructed by default from the
-flux image using the configuration supplied values of GAIN and
-READ_NOISE to calculate the appropriate Poisson statistics for each
-pixel.  In this case, the image is assumed to represent the readout
-from a single detector, with well-defined gain and read noise
+flux image using the configuration supplied values of \code{GAIN} and
+\code{READ_NOISE} to calculate the appropriate Poisson statistics for
+each pixel.  In this case, the image is assumed to represent the
+readout from a single detector, with well-defined gain and read noise
 characteristics.  In some obvious cases, this assumption will not be
 valid.  For example, if the input flux image is the result of an image
 stack with significantly variable number of input measurements per
 pixel, it will necessary to supply a noise image which accurately
-represents the noise as a function of position in the image.  
-
-\subsubsection{Intial Object Detection}
+represents the noise as a function of position in the image.
+
+\subsubsection{Initial Object Detection}
 
 The objects are initially detected by finding the location of local
@@ -231,5 +236,5 @@
 Once a collection of peaks have been identified, basic properties of
 the objects are measured.  First, the local sky flux is measured
-(using Median? user-specifie method?) within a square annulus with
+(using Median? user-specific method?) within a square annulus with
 user-defined dimensions (\code{INNER_RADIUS} and \code{OUTER_RADIUS}).
 \note{rejection of some peaks based on the local sky measurement?}.
@@ -250,5 +255,5 @@
 PSPhot uses an analytical model to represent the shape and flux of an
 object.  An important concept within the PSPhot code is the
-distinction bewteen a model which describes an object on an image and
+distinction between a model which describes an object on an image and
 a model with describes the point-spread-function across an image.  
 
@@ -258,5 +263,5 @@
 ($x_o, y_o$), the elliptical shape parameters ($\sigma_x, \sigma_y,
 \sigma_{xy}$), the model normalization ($I_o$) and the local value of
-the background ($S$).  A specific object will have a partiular set of
+the background ($S$).  A specific object will have a particular set of
 values for these different parameters.
 
@@ -278,7 +283,7 @@
 each a function of the object centroid coordinates: 
 \begin{eqnarray}
-\sigma_x    & = & f1(x,y) \\
-\sigma_y    & = & f2(x,y) \\
-\sigma_{xy} & = & f3(x,y) \\
+\sigma_x    & = & f_1(x,y) \\
+\sigma_y    & = & f_2(x,y) \\
+\sigma_{xy} & = & f_3(x,y) \\
 \end{eqnarray}
 
@@ -314,23 +319,24 @@
 these types of circumstances are abstracted, and a method is provided
 to return the necessary function to the higher-level software.  For
-example, each model type has its own function to define an intial
+example, each model type has its own function to define an initial
 guess for the model, or a function to determine the radius for a given
 flux level.  These are then registered as part of the model function
 code.  Another function is then used to return the appropriate
 function for a specific model type.  For example, the
-psModelLookup_GetFunction will return the psModelLookup function for a
-given model type.  This mechanism makes it very easy to add new model
-functions into the PSPhot code base.  To add a new model function, the
-programmer simply defines a new model name (a string), the set of all
-necessary model lookup functions, and places the reference to the
-model code at the appropriate location in the psModelInit.c routine.
-It is not necessary to specify the PSF model functions independently
-or the object model functions.  Nor is it necessary to identify the
-intended use of a given object model function (ie, PSF-like object,
-galaxy, comet, etc).  Any model can be used for the PSF model.  The
-code currently uses a fixed translation between the object model
-parameters and the PSF model parameters.  It also defines a specific
-order for the 4 independent parameters.  \note{it may also require
-that two of the PSF-like parameters represent the shape in some way}.
+\code{psModelLookup_GetFunction} will return the \code{psModelLookup}
+function for a given model type.  This mechanism makes it very easy to
+add new model functions into the PSPhot code base.  To add a new model
+function, the programmer simply defines a new model name (a string),
+the set of all necessary model lookup functions, and places the
+reference to the model code at the appropriate location in the
+psModelInit.c routine.  It is not necessary to specify the PSF model
+functions independently or the object model functions.  Nor is it
+necessary to identify the intended use of a given object model
+function (ie, PSF-like object, galaxy, comet, etc).  Any model can be
+used for the PSF model.  The code currently uses a fixed translation
+between the object model parameters and the PSF model parameters.  It
+also defines a specific order for the 4 independent parameters.
+\note{it may also require that two of the PSF-like parameters
+represent the shape in some way}.
 
 \subsubsection{PSF Object Candidate Selection}
@@ -339,6 +345,6 @@
 identify a collection of objects in the image which are {\em likely}
 to be PSF-like.  PSPhot uses the object moments to make the initial
-guess at a colletion of PSF-like objects.  At this point, the program
-has measured the second order moments for all objects identified thier
+guess at a collection of PSF-like objects.  At this point, the program
+has measured the second order moments for all objects identified their
 peaks, as well as an approximate signal-to-noise ratio.  All objects
 with a S/N ratio greater than a user-defined parameter are selected by
@@ -353,9 +359,9 @@
 the bin size is approximately 0.1 image pixels.  The binned $\sigma_x,
 \sigma_y$ plane is then examined to find a peak which has a
-significance greater than XXX.  Unless the image is extremely sparce,
+significance greater than XXX.  Unless the image is extremely sparse,
 such a peak will be well-defined and should represent the objects
 which are all very similar in shape.  Other objects in the image will
 tend to land in very different locations, failing to produce a single
-peak.  To avoid detecting a peak from the unresoled cosmic rays,
+peak.  To avoid detecting a peak from the unresolved cosmic rays,
 objects which have second-moments very close to 0 are ignored.  The
 only danger is if the PSF is very small and too many of these objects
@@ -381,5 +387,5 @@
 iterative, and rejects the $3-\sigma$ outliers in each of three
 passes.  This fitting technique results in a robust measurement of the
-variation of the PSF model parametesr as a function of position
+variation of the PSF model parameters as a function of position
 without being excessively biased by individual objects which fail
 drastically.  Objects whose model parameters are rejected by this
@@ -400,5 +406,5 @@
 the PSF objects.  The difference between the aperture and fit
 magnitudes ({\em ApResid}) is a critical parameter for any PSF
-modelling software which uses an analytical model to represent the
+modeling software which uses an analytical model to represent the
 flux distribution of the objects in an image.  
 
@@ -408,5 +414,5 @@
 between two images.  Whether the goal is calibration of a science
 image taken at one location to a standard star image at another
-location, or the goal is simply the repetative photometry of the same
+location, or the goal is simply the repetitive photometry of the same
 star at the same location in the image, it is always necessary to
 compare the photometry between two images.  If this measurement is to
@@ -450,5 +456,5 @@
 Consider a typical bright object with a flux of (say) 40,000 counts in
 an image of background 1000 counts per pixel, with FWHM of 4 pixels.
-In principle, the flux of this object should be measureable with an
+In principle, the flux of this object should be measurable with an
 accuracy of roughly 0.57\% ($\frac{\sqrt{40000 + 1000 \times
 12}}{40000}$).  However, the measurement of the sky is limited at some
@@ -572,14 +578,14 @@
 
 PSPhot will use the user-selected galaxy model to attempt the galaxy
-model fits.  In the configuration system, the KEYWORD GAL_MODEL is set
-to the model of interest.  All suspected extended objects are fitted
-with the model, allowing all of the parameters to float.  The initial
-parameter guesses are critical here to achieving convergence on the
-model fits in a reasonable time.  The moments and the pixel flux
-distribution are used to make the initial parameter guess.  Many of
-the object parameters can be accurately guessed from the first and
+model fits.  In the configuration system, the keyword \code{GAL_MODEL}
+is set to the model of interest.  All suspected extended objects are
+fitted with the model, allowing all of the parameters to float.  The
+initial parameter guesses are critical here to achieving convergence
+on the model fits in a reasonable time.  The moments and the pixel
+flux distribution are used to make the initial parameter guess.  Many
+of the object parameters can be accurately guessed from the first and
 second moments.  The power-law slope can be guessed by measuring the
 isophotal level at two elliptical radii and comparing the ratio to
-that expected.  
+that expected.
 
 For each of the galaxy models (in fact for all object models), a
@@ -642,5 +648,5 @@
 Finally, PSPhot can simply ignore the fitting process and instead
 glean information about the fainter sources on the basis of the peak
-charateristics.  In this option, the image is smoothed with the PSF
+characteristics.  In this option, the image is smoothed with the PSF
 model, and the peak for each object is measured.  The peak flux and
 the local peak curvature theoretically give sufficient information to
@@ -675,5 +681,5 @@
 will automatically result in inconsistent interpretation of the noise.
 
-For a difference image, both positive and negetive objects will be
+For a difference image, both positive and negative objects will be
 present.  The basic peak detection algorithm will only trigger for the
 positive sources.  One solution is to simply apply PSPhot to both the
@@ -703,5 +709,5 @@
 a 30 second exposure.  Even a main belt asteroid at roughly 1 AU would
 have reflect motion of approximately 1 degree per day, equivalent to
-1.25 arcsec in a 30 second exposure, and could be noticably smeared
+1.25 arcsec in a 30 second exposure, and could be noticeably smeared
 and non-PSF-like.  A trailed-star model can be used to characterize
 these types of objects.  2) Small offset stars, either due to