Date: Fri, 17 Apr 1998 15:04:52 -0700 (PDT)
Message-Id: <199804172204.PAA25470@colman.ipac.caltech.edu>
To: 2mass
Subject: IPAC 2MASS WG Mtg #149 Minutes
Cc: chas, stiening, bgreen
Content-Length: 3400
X-Lines: 74
Status: RO

           IPAC 2MASS Working Group Meeting #149 Minutes
                             4/14/98

Attendees: R. Beck, T. Chester, S. van Dyk, D. Engler, T. Evans,
           J. Fowler, L. Fullmer, R. Hurt, D. Kirkpatrick,
           G. Kopan, H. McCallon, B. Nelson,  B. Wheaton,
           J. White
          

          
AGENDA

1.) Analysis/Debugging Utilities



DISCUSSION


1.) Analysis/Debugging Utilities

    It has been found that a frequent activity involved in
analyzing or debugging the pipeline is tracing detections from
one intermediate file to another, usually upstream. The
intermediate files are designed to support this in all cases
where it is possible, but so far it usually has to be done by
hand. A need to automate where feasible has been recognized, and
this opens up the more general issue of organizing the utility
programs developed by some cognizant engineers so that they may
be used by others, and also to avoid duplicated effort. This
organization will also reveal where pieces are missing.
    The desire to organize utilities and fill in blanks includes
a desire not to generate more effort than an organized set of
utilities will save. It is also recognized that many of the
engineers who have developed utilities do not have the time to
produce formal documentation and provide extensive support to
users. But at an informal and low level of effort, it appears
that better use of the existing tools can be made, and it is
consistent with the goal of minimizing effort to eliminate
duplication. Organizing the existing utilities will make it easy
to avoid such redundancy.
    To get this ball rolling, it was decided that anyone with one
or more utility programs that might be of wider usefulness should
send a very brief (e.g., one-line) description to J. Fowler via
email. These will be formatted into a file similar in concept to
the SIS listing file /2massc/doc/design/sis/sislist, which
simplifies finding the SIS governing a particular software
interface. The utility list will be placed in a file named
utilist in the directory /2massc/doc/utils. The utilities
themselves will either be placed in /2massc/utl/bin, or else the
entry in the utilist file will provide path information (some
members preferred not to "deliver" their utilities but rather to
let people use them from wherever they were developed and
upgraded; some further discussion of whether change-without-
notice software is more desirable than outdated-but-stable
software seems useful, however).
    T. Evans pointed out that it is often necessary to relate the
MAPCOR Read1 input (the exr1 file) to the FREXAS output; the
Read1 ID can now be related to the merge number in the exr1 file,
and from there the parameters needed to find the original fex-
file entries are available. This usually has to be done by hand;
J. Fowler agreed to look into automating it. It was also noted
that downstream from BANDMERGE, the final point-source ID is
always related to the single-band ID numbers; this makes it
possible to link back to the MAPCOR and PROPHOT output files, and
this also should be automated. It would probably be desirable to
be able to trace from any downstream point-source file all the
way back to the origins of all its component detections
automatically.
    Team members are requested to consider other automatable
needs and current capabilities and report them to J. Fowler.