IPAC 2MASS Working Group Meeting #79 Minutes

IPAC 2MASS Working Group Meeting #79 Minutes, 11/21/95

Attendees: R. Cutri, T. Evans, J. Fowler, T. Jarrett, D. Kirkpatrick, G. Kopan, B. Light, H. McCallon, S. Terebey, J. White

AGENDA

  1. 2MAPPS Coding Requirements
  2. Hemisphere Classification
  3. Blended Point-Source Processing

DISCUSSION

  1. 2MAPPS Coding Requirements -- The FDD section on coding requirements (section 2.6) specifies the use of the flint utility and the -u compiler option for FORTRAN programs (the lint utility is also required for c programs, but there is no corresponding compiler option, since variable declarations are required by default). J. Fowler reported that both of these tools proved useful in developing the PIXCAL/DFLAT code that was recently put into subsystem testing. Several bugs were exposed before they had a chance to cause problems. The flint utility does produce a few false alarms, but the Solaris version appears to have cut down on these significantly compared to the SunOS version, and very little time was required to wade through them and the warnings. The recommended options for flint are illustrated by the following command line, which shows how a subsystem named "abc" would be processed: 
                 flint -gtxs -Sabc *.f
    where it is assumed that the default directory contains all FORTRAN source files involved. This command line causes files to be created in the directory with the names of the form "abc.tre", "abc.xrf", "abc.stt", and "abc.lnt" for calling tree, cross-reference, statistics, and lint-style error checking. By using *.f with all source files in the directory, flint is able to check for consistency of calling lists and COMMON blocks across all routines involved. The files generated by flint can be inspected with a text editor.

  2. Hemisphere Classification -- J. White reported that the current scheme for executing the pipeline programs does not distinguish between northern and southern hemispheres. This may imply that the EXEC subsystem keeps track of this distinction by executing the software within a directory tree structure in which the technical routines do not need to know which hemisphere is involved. If so, then EXEC will have to arrange for such things as setting up the correct NAMELIST files for programs which have hemisphere dependent parameters. Alternatively, the hemisphere distinction can be built into the directory structure in a way such that a hemisphere code is passed to the programs in the same way that scan number and band identifiers are, allowing the programs to make the distinctions for themselves. A splinter group will decide how to incorporate the hemisphere distinction into the automated processing, with J. White and G. Kopan being the primary members. Other interested people are invited to join them in this activity. Some SIS's may be affected by the decision arrived at by this splinter group.

  3. Blended Point-Source Processing -- R. Cutri reported that the primary causes of incompleteness and unreliability in the protocamera data products are blending of point sources and confusing of close but separately detected point sources. KAMPhot and PROPhot are designed to apply up to three PSF templates to a blob of flux if this produces a better overall fit chi-square. This processing may be applied to a single detection or to multiple close detections. In general, the product of this processing is not the same in all three bands. Although the protocamera had only single band scans, and consequently scans of the same sky in different bands involved independent scanning registration errors, the three band scans provided by the survey hardware can be expected to yield different details in the fine geometry of the separate bands so that similar band dependent deblending results will be obtained in some significant fraction of the cases.

    When deblending produces different results in different bands, fragments of point sources are generally obtained which are neither complete nor reliable representations of the sources involved. Some standard fixup for this situation is very desirable, but it is not clear what this should be. Clearly, recourse to the original raw frame data would allow optimal extractions to be performed, but multi-passing the raw data or processing all bands simultaneously in PROPhot are not even close to being viable options because of hardware limitations and the relatively infrequent occurrence of deblending processing.

    If possible, it would be desirable to control the deblending algorithm so that consistent results are obtained in all bands. This does not appear to be possible, however, since any thresholds will always have events occurring randomly above or below them on different occasions, and the geometrical details of flux falling on pixels will not be the same in all bands (the varying plate scale alone will cause this). Even eliminating the deblending code would not prevent sources from being resolved in some bands and combined in others.

    It was suggested that whatever corrective action is to be applied be implemented in BANDMERGE, since that is the first time that point source extractions in different bands are brought together. BANDMERGE will know when a single source in one band has close multiple matches in another, and PROPhot provides a blending flag that tags the products of this processing. BANDMERGE could theoretically recombine separate pieces to match single objects in other bands (applying some splitting algorithm to break up single sources to match multiple objects in another band does not appear feasible). Another action could be to bandmerge the best fragment, write the others to a special file, and set a pointer in the bandmerged output source record to indicate where to find the additional pieces (a nonzero pointer would also serve to flag the condition). A variation of this idea would be to output a recombined entry and add pointers to all the original separate fragments (actually, a single pointer to an entry in the "fragment file" would suffice, with the other entries accessible via a linked list, with the last entry indicated by a zero pointer); this would allow users to ignore the fragment file easily if they wished to do so, leaving them with the best available recombined entries.

    Another possibility is for GALWORKS to apply templates to the coadded images at indicated locations to extract multiple sources where a single one was produced by PROPhot in the given band but multiple objects were found in another band. A problem with this is that it does not match identically what PROPhot does to extract sources, since PROPhot uses the single frames and corresponding PSF templates. Such templates would not be appropriate for use in the coadded images. For GALWORKS to do anything at all is suggested because of the fact that band filling is to be done in this subsystem.

    No decision can be made without science team input, but the discussion served to define the problem and several possible approaches to its solution. In the meantime, the BANDMERGE SDS will contain a lien stating that it does not attempt any corrective action for cases of this sort. The lien will give visibility to the problem until such time as a decision is made by the project about how to handle it.