IPAC 2MASS Working Group Meeting #74 Minutes

IPAC 2MASS Working Group Meeting #74 Minutes, 9/26/95

Attendees: C. Beichman, T. Chester, R. Cutri, T. Evans, J. Fowler, L. Fullmer, T. Jarrett, D. Kirkpatrick, G. Kopan, B. Light, C. Lonsdale, H. McCallon, M. Moshir, S. Terebey


  1. SDS and SIS Work
  2. PSF Handling
  3. RoboChart
  4. Science Team Advisers


  1. SDS and SIS Work --- T. Evans suggested that a central location for SDS's should be set up so that developers could obtain quick and easy access to other developers' latest SDS's. This sort of thing has been done for SIS's. J. Fowler will make a directory named /proj/2mass/doc/design/sds for this purpose and send an email message to the cognizant engineers with suggested usage guidelines (this message was sent later and is attached to these minutes).

    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.

  2. PSF Handling --- T. Evans reported that MAPCOR needs information regarding seeing variations, since these affect the size of the aperture used in computing aperture photometry corrections. This makes MAPCOR the third user of the intersubsystem function PSFMAN, which is the centralized provider of seeing/PSF information. One of the two existing users was GALWORKS, which now appears to be eliminating its use of PSFMAN in favor of a more directly useful seeing measure computed from the coadds within its own code.

    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.

  3. RoboChart --- B. Light's experiments with RoboChart have resulted in the software being ordered. J. White and T. Evans also experimented with it and concurred on its desirability. An attempt to obtain it and get it installed as rapidly as possible will be made, and the team will be notified as soon as it is usable.

  4. Science Team Advisers --- R. Cutri reported that some of the developers have not yet contacted the Science Team advisers for their subsystems. He requested that they do so. Any needed information on how to do this may be obtained from Roc.

================================ 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
========================= END OF ATTACHMENT ====================================