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.