Date: Thu, 2 Apr 1998 10:58:32 -0800 (PST) Message-Id: <199804021858.KAA26487@colman.ipac.caltech.edu> To: 2mass Subject: 2MASS WG Mtg #147 Minutes Cc: chas, firstname.lastname@example.org, stiening, bgreen Content-Length: 5011 X-Lines: 108 Status: RO X-Status: IPAC 2MASS Working Group Meeting #147 Minutes 3/31/98 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 AGENDA 1.) 2MAPPS 2.0 RTB Status 2.) Date Handling 3.) Documentation Updates 4.) New Responsivity and Mask Handling DISCUSSION 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 status. 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 masks].