From jwf@ipac.caltech.eduSat Mar 29 10:01:19 1997 Date: Fri, 28 Mar 1997 13:07:54 -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 #119 Minutes IPAC 2MASS Working Group Meeting #119 Minutes 3/25/97 Attendees: R. Beck, R. Cutri, T. Evans, J. Fowler, T. Jarrett, B. Light, H. McCallon, S. Wheelock, J. White AGENDA 1.) 2MAPPS Test Results 2.) Scan Direction Definition 3.) Position Reconstruction Biases DISCUSSION 1.) 2MAPPS Test Results R. Cutri reported on the results of the latest 2MAPPS test runs. On the positive side, photometric dispersion of the M67 test fields has been signficantly reduced, and other previously recognized problems (such as those related to incomplete Read1 merging) appear to be alleviated. On the negative side, new problems have appeared: some job steps have returned negative error codes, and BANDMERGE and POSPTS have both terminated abnormally on some MSX scans. J. Fowler reported that the cause of the BANDMERGE problem is known and has been fixed, but whether this will affect the POSPTS problem is unknown. Work will continue on this and the negative return codes. [Note added in proof: The POSPTS problem was related to a typographical error in BANDMERGE which has now been fixed and redelivered; the negative return codes were generated by the unix operating system when the FORTRAN programs terminated abnormally and were thus unable to set their own return codes; wrapper scripts will be modified to convert any negative return codes to positive 4 return codes, indicating failure of the job step.] 2.) Scan Direction Definition The observatory proposal to change the scan direction indication from ascending vs. descending (A/D) to northward vs. southward (N/S) was accepted by the working group, subject to additional clarification regarding chip orientation. The proposal was made in order to eliminate ambiguity about what an "ascending scan" is in the southern hemisphere. The N/S values for the parameter named "Scan Direction" achieve this as far as celestial direction is concerned, but not necessarily as far as the motion of object images through chronologically ordered frames is concerned. The latter phenomenon is equally important to 2MAPPS processing. If the southern observatory were to use a chip orientation that results in south at the top of images as currently created from data frames, the N/S specification alone would not suffice for successful analysis of the data. The group recommendation was to add the following specification: the (0,0) pixel (as defined by the current readout and data formatting conventions) will correspond to the southeast corner of the area imaged in the data frame that begins a scan. This assumes that scans of tiles with a celestial pole at one end will always start from the end farthest from the pole; if this turns out not to be true, then the SE corner definition will be defined as applying at the time of tile center crossing. 3.) Position Reconstruction Biases As reported last week, H. McCallon has been investigating certain position biases. One of these has been resolved: the Read1/Read2-Read1 bias (as indicated in the note added to last week's minutes). The other bias is not yet understood; this was described as a scan-to-overlapping-scan bias, but Howard has discovered that it involves a bias between positions assigned to sources in a scan at one point in the pipeline and the corresponding positions of those sources at other points in the pipeline. Since sources are represented in different coordinate systems at different pipeline points, a fairly general utility had to be written to perform various coordinate transformations and source associations. Application of this utility has narrowed the range of where the bias is generated to somewhere after POSFRM and before BANDMERGE, although some amplification of the bias in the scan direction may take place in BANDMERGE. Histograms of the bias indicate that in the few scans studied so far, it runs from about 0.05 to 0.2 arcsec, with a mean of typically about 0.1 arcsec on both axes. For comparison of POSFRM output to MAPCOR output, the POSFRM positions are transformed to band-scan coordinates to match MAPCOR's convention, and the single-band MAPCOR sources are associated with the multi- band POSFRM sources, and the latter positions are subtracted from the former. The result is a positive bias in all bands with a mean of typically 0.1 arcsec on both axes. After BANDMERGE, U-Scan coordinates are used, and both sets of sources are multi-band; the X bias remains, and the Y bias appears to be approximately doubled. The bias does not appear to depend on scan direction, but more scans need to be studied before direction dependence can be ruled out. If the bias is as systematic as it appears, it will be removed by POSPTS when the latter program is fully implemented. For now, it is simply desirable to understand the origin of the bias, which may turn out not to be of concern as long as it is understood and removed effectively by POSPTS. Howard's utility program will be used as a diagnostic to detect any sudden disappearance of the bias, which could happen when a software redelivery is made for some other purpose. Correlating such a disappearance to the redelivery should shed light on the origin of the bias if it is not found sooner. Some investigation will be done to determine whether the bias varies along the scan.