Date: Thu, 2 Apr 1998 10:58:32 -0800 (PST)
Message-Id: <>
To: 2mass
Subject: 2MASS WG Mtg #147 Minutes
Cc: chas,, stiening, bgreen
Content-Length: 5011
X-Lines: 108
Status: RO

           IPAC 2MASS Working Group Meeting #147 Minutes

Attendees: R. Beck, T. Chester, R. Cutri, S. van Dyk, D. Engler,
           T. Evans, J. Fowler, L. Fullmer, R. Hurt, T. Jarrett,
           D. Kirkpatrick, G. Kopan, J. Mazzarella, H. McCallon,
           B. Wheaton, S. Wheelock, J. White


1.) 2MAPPS 2.0 RTB Status
2.) Date Handling
3.) Documentation Updates
4.) New Responsivity and Mask Handling


1.) 2MAPPS 2.0 RTB Status

    R. Cutri reported that 2MAPPS appears to be stabilizing and
that a new RTB is about to begin which is hoped to be the last
before production can start around the middle of next week. When
that happens, northern production will be done on barney, with
elvis as its tape machine, and the southern production and
testing will be done on rex with holly as its tape machine. The
parallel-processing machine, where tests of 2MAPPS versions
beyond 2.0 will be developed and tested, will be rodan, which
will also serve as a backup for barney and rex, and may possibly
be used to help get the production processing caught up with the
data acquisition. Version 2.1 for full southern production is
targeted for June, shortly after the Science Team meeting, which
will be in San Diego, coordinated with the AAS meeting there.

2.) Date Handling

    R. Cutri pointed out that because of the southern
observatory's time zone, UT dates generally change during the
night and usually in mid-scan. He requested that the cognizant
engineers of any subsystems dependent on time tags review such
usage for possible problems due to this, since it does not happen
at the northern observatory and dependences could therefore have
been missed. J. White reported that he had completed such a check
of the RDFRAME module, and it is free of problems of this sort.

3.) Documentation Updates

    In anticipation of the start of production next week, all
subsystem cognizant engineers are requested to review their
Subsystem Design Specification (SDS) and Software Interface
Specification (SIS) documents and bring them up to date. The
SIS's have the highest priority, and attention is called to lien
lists, which should be kept in the SDS's. It is important to
identify clearly any liens in effect as production begins. In
some cases, liens may be no longer relevant or may have reduced
priority; if such liens are to be dropped, the documentation
should continue to identify them but indicate that they are no
longer considered liens; they should not be deleted from the
documentation, since there may be a need to keep track of what
became of them.

4.) New Responsivity and Mask Handling

    J. Fowler reported that the recently delivered version of the
DARKS subsystem, which will be used in the new RTB and standard
cal-scan quality checking, incorporates the 5-night moving-window
average responsivity capability. This makes use of a routine that
searches the darks history directories backwards in time from the
observation date to be processed, identifies the most recent five
containing a complete set of accepted darks and responsivities,
and reports these to the main DARKS program. The latter then uses
those responsivities to compute an average "grand canonical"
responsivity for each band that is used in acceptance-testing the
new responsivities. If there are no twilight flat sequences, or
if there are but not all bands pass acceptance testing, then the
grand canonical responsivities are used by the pipeline for scan
processing; otherwise the most recent four sets of accepted
responsivities are averaged with the new ones to obtain the
responsivities used for scan processing. In order for this to
work, R. Cutri and J. Fowler retroactively elevated all past
acceptable responsivities to the new format identifying canonical
    J. Fowler also reported that a new approach to the use of
masks will be implemented in time for production, but not for the
new RTB. The desire to freeze the masks and the conflicting need
to keep up with changes in the hardware have led to a compromise
in which the masks will be frozen over periods of time between
camera warmups or other significant hardware changes. The masks
for each such period will be frozen and will be computed by
averaging the new information-only masks computed by the DARKS
subsystem for nights with acceptable dark and flat sequences. The
averaged masks will be thresholded at some level below which the
mask will be set to zero (pixel off) and above which it will be
set to 1.0 (on). Histograms of the averaged masks will be used to
set thresholds. New utility programs to do the averaging over the
relevant time periods and thresholding have been written and
tested [Note added in proof: there is also now a utility for
turning off pixels listed in a file, so that known hot pixels can
be forced off; normally this option is provided by DARKS, but
that program is unwieldy as a tool for manipulating the averaged