J. Fowler reported that some small format changes have become desirable for SIS's and SDS's. Since the SIS's are to be pure-ASCII text files and will be primarily viewed on computer monitors, maintenance would be eased by eliminating the "Page N of M" item from the top header, allowing the file to be manipulated without pagination; the version IDs and dates should be updated scrupulously, however, whenever changes are made, and should be referenced wherever the SIS is referenced (i.e., primarily in SDS's). The SDS Table of Contents structure should be modified such that Section 1 has the following title and subsections:
1. Overview
1.1 Requirements
1.2 Applicable Documents
1.3 Version History
Narrative description can be placed in section 1. (or 1.0, if the
trailing zero is preferred), and section 1.1 should contain a list of
requirements on the subsystem that indicate what parts of the overall
system tasks the subsystem performs. This list should be designed for
ease of use by reviewers, and the items need not be quantitative at
this time unless corresponding subsystem allocations have been budgeted
from the system requirements and assigned to the subsystem.
The recognition that seeing could change significantly during a scan reopened the difficult question of how to handle seeing and the PSF as a function of time, a question some team members thought had been settled as far as the baseline approach within 2MAPPS was concerned. This supposed baseline was: (a.) FREXAS computes the "seeing parameter" known as "pfrac" (the fraction of a point source's light falling on the central pixel if the center of the point-source image is centered on the pixel) by employing a histogram method that requires some minimum number of single-frame point-source extractions above some threshold S/N, say N extractions; (b.) every time N extractions are obtained, an estimate of pfrac is written with time tags to a disk file; (c.) PSFMAN is called by any user needing seeing/PSF information; a time tag is input to PSFMAN via its calling list; (d.) PSFMAN reads the data produced by FREXAS to supply the requested information.
The relationship between pfrac and the PSF needed by PROPHOT (the other user of PSFMAN) would be calibrated during the initial shakedown period and be refined during the survey. The highest-frequency variations in seeing/PSF parameters would be controlled via the centralized function PSFMAN, leaving users free to design their subsystems without having to figure this out to a large extent (probably not completely, since calling PSFMAN for every event processed would presumably be less efficient than calling it only once every so often and using the last result for some period of time).
Concern has been expressed for some time throughout the project about the time resolution of seeing/PSF estimation and usage. The idea that one and only one PSF estimate is needed within a single scan (per band) does not sit well. On the other hand, joysticking an imperfectly modelled PSF at unconstrained frequencies is certainly to be avoided. And for some reason yet to be made clear to the entire team, the GALWORKS developers have decided that they can compute a better estimate of the seeing (at least for their own purposes) than PSFMAN can deliver, perhaps because their estimate is obtained from coadded images, which are generated by PICMAN as it executes its intricately choreographed duet with PROPHOT. The latter could conceivably benefit from the former's use of the GALWORKS algorithm to compute a PSF at least almost up to the point in time being processed, but it would not yet be known what the PSF is going to do for the remainder of the scan, hence that information could not be used to smoothe or otherwise refine the PSF estimate. There might be such information from previously executed calibration scans when doing survey scans, since the calibration scans are to be processed in their entirety before any survey scans, but the question remains about calibration scan processing. The possibility of using the FREXAS pfrac information (available for the whole scan in PICMAN/PROPHOT) in combination with the GALWORKS algorithm estimate (available up to the point being processed) was discussed, as was the possibility of splitting up PICMAN and PROPHOT, with the latter running after the former has finished and consequently performing a great deal of additional I/O.
At this point, it appeared that significant complications to the software (along with the attendant risk) were being argued without good proof that the existing design (as variously understood) was inadequate. There appeared to be no obvious place to lock onto in the cost/benefit curve relating seeing/PSF estimation accuracy/stability to software design/interface effort. The following compromise was suggested and subsequently adopted: (a.) PSFMAN will be capable of using the FREXAS pfrac data set or a similar data set generated by GALWORKS; (b.) GALWORKS will generate a disk file containing its version of a time history of the seeing; (c.) the QUALITY subsystem will compare the two seeing histories and reach one of three conclusions: (c1.) the histories agree satisfactorily; (c2.) the histories disagree, but the GALWORKS version is acceptable, in which case reprocessing will be performed with PSFMAN directed to use the GALWORKS seeing data; (c3.) the histories together or separately indicate that the seeing was unacceptable, in which case the sky involved must be rescanned.
This approach minimizes the impact on all the software other than PSFMAN and QUALITY, and it allows the design to proceed without having to commit now to a policy about the frequency at which seeing/PSF variations will be modelled, while leaving the option open to do this modelling at the highest frequency permitted by the point-source densities encountered and the interleaving of calibration and survey scans.
================================ ATTACHMENT ==================================
From: jwf Date: Tue, 26 Sep 95 18:16:01 PDT
To: 2mass
Subject: SDS Directory
I have made a directory named /proj/2mass/doc/design/sds for storage of
latest-version SDS's. After talking to a few team members, I propose
the following guidelines.
1.) File names should be based on the subsystem name followed by a
period and then "ps" for postscript files, "txt" for pure-ASCII text
files, and some identifier for propietary word-processor format
files (e.g., "wp51" for WordPerfect 5.1).
2.) Each SDS should be present in postscript form and native
word-processor form. If the latter is not pure-ASCII, then
a pure-ASCII form should also be present. Multiple-subsystem
SDS's (e.g., PIXCAL/DFLAT) should use a dash in place of the
slash in the file name.
Example: I am doing PIXCAL/DFLAT in WordPerfect 6.1, so I will put
the following three files in /proj/2mass/doc/design/sds:
pixcal-dflat.wp61 (WordPerfect 6.1 native format)
pixcal-dflat.ps (postscript file)
pixcal-dflat.txt (pure-ASCII text format)
The pure-ASCII format will serve as native-format for TeX and LATeX
documents. In general, these will not have readable equations,
flow- charts, or other graphical contents.
3.) This directory should not be the storage location for the primary
copy of the document; it will be a public area where clobbering can
occur, so each Cog. E. should maintain a separate working directory
with all needed files, and the usual backup procedures should be
implemented. In the example above, it seems unnecessary for
graphics files that are linked into the document to be present
also, as long as they are properly incorporated into the postscript
version.
========================= END OF ATTACHMENT ====================================