Date: Fri, 20 Mar 1998 19:15:17 -0800 (PST) Message-Id: <199803210315.TAA17271@colman.ipac.caltech.edu> To: 2mass Subject: 2MASS WG Mtg #146 Minutes Cc: chas, email@example.com, stiening, bgreen Content-Length: 7895 X-Lines: 166 Status: RO IPAC 2MASS Working Group Meeting #146 Minutes 3/17/98 Attendees: R. Beck, T. Chester, R. Cutri, D. Engler, T. Evans, J. Fowler, L. Fullmer, T. Jarrett, D. Kirkpatrick, G. Kopan, J. Mazzarella, H. McCallon, B. Wheaton, S. Wheelock, J. White AGENDA 1.) Southern Observatory Status 2.) PFPOST/COMBINE/MAPCOR Changes 3.) Possible BANDMERGE Change DISCUSSION 1.) Southern Observatory Status R. Cutri reported that the first-light scan from the southern observatory had run through 2MAPPS without problems, as have several subsequent scans. A near-optimal dither pattern has been obtained, and a Stone astrometric field has been observed, so the computation of a distortion map should be possible soon. The glint pattern is rotated 180 degrees relative to the northern telescope, as expected. 2.) PFPOST/COMBINE/MAPCOR Changes H. McCallon and J. Fowler described changes to PFPOST and its counterpart to PROPHOT's COMBINE routine. The original "nmerge" numbers (sequential numeric identifiers assigned to groups of merged detections in PFPREP), hereinafter referred to as "nmerg0", have been appended to the EXR1 file (SIS POS02) and the SOLO file (SIS POS10) to aid in tracking detections backwards from MAPCOR or PIXPHOT through POSFRM to FREXAS. The SIS POS02 discussion of the "nmerg0" parameter is included herein: "Merge numbers" are numbers sequentially assigned to merge groups as these are formed by PFPREP. Because of the order in which different bands and read types are used to supply "seed" detections for merging, the first merge numbers assigned to groups of merged detections are not monotonic functions of declination, so after declination sorting is performed, new merge numbers are assigned. The merge numbers in this file, however, are written out before the new ones are assigned, hence these are called the "original" merge numbers. They are not the same as the merge numbers in the EXTM file, but they can be used to trace detections back from MAPCOR to FREXAS by rerunning POSFRM and saving the fort.61 file, which is very similar to the EXTM file but has the "original" merge numbers. In addition, the rules for combining multi-apparition aperture magnitudes have been changed for two reasons: (a.) as discussed in the minutes of the previous meeting (no. 145), the former computation of mean magnitudes and associated uncertainties was inconsistent; the new computation corrects this; (b.) additional information is needed by MAPCOR to handle persistence objects more effectively; the new computation in the PFPOST "COMBINE" code provides this. The first change is that in both "COMBINE" computations, no inverse-variance weighting is used in photometric averaging, and the "uncertainty" parameter has been replaced with the "reduced population sigma estimate", which is just the square root of the observed sample variance divided by one less than the number of measurements averaged; this parameter is discussed in the SIS POS02 as follows. The "reduced population sigma estimate" should NOT be considered a photometric uncertainty under any circumstances. When its value is 9.999 (see note 1*, items B, C, and D above), it is just a flag indicating that the magnitude is unreliable or missing; otherwise its value indicates how much the observed magnitudes varied, which cannot be used as an uncertainty (e.g., it could be zero purely because of random noise), and is intended only to be used in computing final photometric uncertainties during final catalog preparation. [*: this is a description of the different averaging methods applied to different kinds of measurements; the types B, C, and D are the same as in the further excerpt from POS02 included below.] The other changes apply only to the code in PFPOST. Here, the unweighted position averaging has been replaced with inverse- variance weighting in order to limit the effect of larger errors in saturated measurements while allowing for the possibility that there are no unsaturated measurements. The other changes involve photometric averaging and are described in the POS02 SIS as follows. The average magnitude "mag" and its one-sigma parameter "msig" can be computed in four different ways. The PFPOST module maintains two separate sums of the input magnitudes, one for "good" detections and one for "bad" detections. "Good" detections are defined as detections for which the reported magnitude is less than 99.9, the reported uncertainty is less than 9.99, and both the saturation and bad-pixel counters are zero. "Bad" detections are defined as detections for which the magnitude is less than 99.9, but the reported uncertainty is greater than 9.98 (these are detections with template magnitudes substituted for aperture magnitudes of 99.999 by PFPREP). All other detections are "useless" detections. A.) If the number of "good" detections is more than one, the output is the unweighted average magnitude, and the one-sigma parameter is the square root of the reduced population variance estimate, i.e., the square root of the sum of the squared deviations from the mean divided by N(N-1) inside the square root. B.) If the number of "good" detections is one, the output magnitude is the one "good" magnitude, and the one-sigma parameter is set to 9.999. C.) If the number of "good" detections is zero, but the number of "bad" detections is greater than zero, then the output magnitude is the unweighted average "bad" magnitude, and the one-sigma parameter is set to 9.999. D.) If the number of "good" detections is zero, and the number of "bad" detections is zero, the output magnitude is set to 99.999, and the one-sigma parameter is set to 9.999. Note that types B and C would be indistinguishable downstream. Although no problem that would result from this has been identified, the ambiguity is removed by forcing type B to end in an odd digit and forcing type C to end in an even digit. For example, a magnitude of -2.123 would be type B, while a magnitude of 7.320 would be type C. T. Evans described the changes to MAPCOR and the way in which the new information would be used in persistence processing. A key point was that Type B and C detections would not be passed downstream, but rather they were only for artifact processing. Some discussion of this resulted in the decision to pass such detections on after all, since they were in fact created by the detection and photometric processing, and their "sigma parameters" having the value of 9.999 mark them clearly as not the sort of information intended for inclusion in the final catalog. Other details of the MAPCOR decision branching were described that are too intricate for inclusion herein, and Tracey agreed to incorporate a flowchart in the MAPCOR SDS for future consultation when questions arise about how certain combinations of photometric parameters are handled. 3.) Possible BANDMERGE Change J. Fowler reported that if, as described at the end of the previous section, the "Type B and C" detections are passed downstream, then they will probably cause problems in BANDMERGE unless some special rules were enforced. For example, detections marked as confused in their "purge flags" are currently not permitted to participate in band-merging. Something similar could be invoked for detections with photometric "sigma parameters" set to 9.999. This issue awaits further discussion.