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, sstrom@donald.phast.umass.edu, 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.