From jwf@ipac.caltech.eduTue Mar 25 09:38:22 1997 Date: Sun, 2 Mar 1997 14:48:28 -0800 From: jwf@ipac.caltech.edu To: 2mass@ipac.caltech.edu Cc: chas@ipac.caltech.edu, sstrom@ipac.caltech.edu, stiening@ipac.caltech.edu Subject: WG Mtg #116 Minutes IPAC 2MASS Working Group Meeting #116 Minutes 2/25/97 Attendees: R. Beck, R. Cutri, T. Evans, J. Fowler, L. Fullmer, T. Jarrett, G. Kopan, B. Light, H. McCallon, S. Wheelock, J. White AGENDA 1.) Scan Direction Definition 2.) Telescope/Camera Status 3.) Digitized RA 4.) Sources Missed by BFILL in Partial Coadds 5.) Karloff Dedication to DataBase Usage 6.) Missing Four Corners Files 7.) Coadd Noise DISCUSSION 1.) Scan Direction Definition R. Cutri asked whether the definition of ascending scans is that the scan direction is northward, independent of hemisphere. No one knew whether the meaning of the term "ascending scan" was different in the southern hemisphere. J. Fowler pointed out that the IPAC ADDSCAN, FRESCO, and HiRes programs all use a convention in which positive scan direction is northward, independent of other considerations (as in 2MASS, IRAS scan directions were never close to East-West, so no ambiguity arose). R. Cutri accepted the task of determining whether the project is consistent throughout in its definition of scan direction. 2.) Telescope/Camera Status R. Cutri reported that optical alignment delays have resulted in slipping first light to late February. Scattered-light fixups are being performed on the camera. The survey start date is now May 1. Three-channel data are expected at IPAC around the end of March. 3.) Digitized RA L. Fullmer reported that the digitized differences in right ascension have ceased to be observed. These were caused by carrying RA as a REAL*4 variable in BFILL (the band-filling module), which resulted in loss of precision such that when CONMAN computed position differences, digitization at about 0.1 arcsec was observed. The change to REAL*8 was made, and BFILL was redelivered. [Note: it was later found that the change in the FORTRAN structure used for point sources in BFILL had caused the compiler to modify its byte-boundary alignment fixups, yielding a structure size larger than expected, so that memory allocation fell short, and segmentation faults caused some scans not to be finished; the REAL*4 version was redelivered pending tests of memory allocation to determine the minimum acceptable size, so in the meantime, digitized RA differences will reappear.] 4.) Sources Missed by BFILL in Partial Coadds S. Wheelock reported that point sources missing from the *.bfpts files (the band-filled point sources) in descending scans were no longer missing. This problem occurred in the last coadd of descending scans, because the band-filling module BFILL and the main program GALWORKS were using inconsistent definitions of the coordinate zero points in these partial coadds. This was repaired in the same redelivery mentioned in the previous item. 5.) Karloff Dedication to DataBase Usage T. Evans reported that the karloff disks need to be dedicated to data base usage at this time (or phased in over the next few weeks). The team was polled for information concerning usage of the protocam data that remain on karloff, and agreement was reached on phasing out such data, which can be restored from tape onto lugosi as needed. 6) Missing Four Corners Files L. Fullmer reported that the four-corners files were missing for some MSX scans. H. McCallon will investigate the reason for this and provide the needed corrections. 7.) Coadd Noise G. Kopan reported that in studies conducted with T. Jarrett, it has been found that the noise in coadded images is about 20% higher than one would predict from the noise in the individual frames being coadded. It is possible that the larger masked-pixel dropout rate of the 4x4 Weinberg kernel (as compared to the previous 3x3 kernel) may contribute to this. G. Kopan will investigate further. [Note: G. Kopan subsequently found that the frame noise is frequently very non-Gaussian, causing the individual frame noise to be underestimated; this may indicate a problem in the frame-flattening method, or it may be a simple by-product of the hybrid trimming algorithm in DFLAT; in any case, G. Kopan has augmented the noise estimator so that it is not thrown off by the presence of this non-Gaussian noise.]