Date: Thu, 18 Dec 1997 10:26:18 -0800 (PST)
From: jwf@ipac.caltech.edu
To: 2mass@ipac.caltech.edu
Cc: chas@ipac.caltech.edu, sstrom@donald.phast.umass.edu,
    stiening@ipac.caltech.edu
Subject: 2MASS WG Mtg #139 Minutes

           IPAC 2MASS Working Group Meeting #139 Minutes
                            12/16/97

Attendees: R. Beck, R. Cutri, J. Fowler, D. Kirkpatrick,
           G. Kopan, B. Light, H. McCallon, B. Nelson, J. White

          
AGENDA

1.) North, South, and Development Pipelines
2.) Combining Single-Frame Detections
3.) PSF Handling
4.) Refraction and Distortion
5.) 2MAPPS 2.0 vs. Southern Telescope Test Support



DISCUSSION


1.) North, South, and Development Pipelines

    The observatory-peculiar data for the northern and southern
observatories must be kept separate, but the 2MAPPS software
itself must be independent of hemisphere. There are two reasons
for the latter: (a.) it provides flexibility in allocating
hardware resources; (b.) maintaining parallel but different
versions of large software systems is costly, risk-laden, and to
be avoided if at all possible. With the imminent arrival of data
from the southern observatory, the group felt that a
clarification of how these principles are going to be implemented
was needed.
    The original 2MAPPS system design included utilization of a
directory tree structure with parallel north-south branches.
Specifically, north and south configuration-controlled data
directories will exist and will be known as the "datan" (data
north) and "datas" (data south) directories. The datan directory
has been used since the beginning of production processing. Since
the datas directory will soon come into use, it is now of crucial
importance that hemisphere-dependent data files be delivered to
/2massc/del/datan and /2massc/del/datas, and not via the software
delivery directories, /2massc/del/src/{subsystem}. The latter
shortcut has been taken on occasion, and this must no longer be
done.
    The intent is to dedicate separate machines to the two
hemispheres, rodan for the north, and barney (or possibly another
similar machine) for the south, but as noted above, the
flexibility designed into 2MAPPS will permit variations on this
theme as appropriate. Also, each machine will have its own copy
of the 2MAPPS software for the sake of redundancy and decoupling
of failure modes, but these copies are required to be identical.
It is probable that there will be a third processing machine for
working backlogs of data, especially for the northern
observatory.
    It was pointed out that temporary overrides to standard data
values have been needed frequently in the northern processing,
and this will probably continue, especially during the early
phases of southern-data processing. It was decided that each
hemisphere's directory structure should contain a "waiver"
directory which would normally be empty, but whose contents would
override the corresponding datan or datas contents during 2MAPPS
initialization for processing an observation date. This should
eliminate accidental re-inclusion of "temporary" data changes.
    The desired "development pipeline" (see last week's minutes)
can be thought of as essentially another hemisphere in terms of
operating on a separate machine and having isolated data, but
differing in that its software is not a copy of 2MAPPS version
2.0. Apparently the CPU could be that of a kinski-class machine
(or current replacement), or possibly even various desktop Sparcs
in the building. The problem seems to be disk space, which would
probably be the main expense.


2.) Combining Single-Frame Detections

    The process of equalizing the "combine" code in PROPHOT and
PFPOST has been completed, and the resulting decisions were
presented to the team for final approval by B. Light and J.
Fowler. The "combine" code is the logic that takes a group of
single-frame detections in one band as input and generates a
single source as output. The changes to the previous
implementations are: (a.) negative-flux encoding is implemented
(this is done to avoid biasing the noise, i.e., negative
contributions to the average are included); (b.) the output
photometric uncertainty is now computed as a reduced Gaussian
variance (previously an average uncertainty was computed; the
change reflects the improved photometric estimate obtained via
the flux-averaging process); the sample dispersion is used to
estimate the population variance, which is divided by the number
of measurements; if this is larger than the reduced Gaussian
variance, it is used instead of the latter as the photometric
uncertainty. The team agreed with these changes; the only concern
about computing too small an uncertainty was alleviated by the
fact that the photometry routine's photometric error model
enforces a safe minimum uncertainty.
    A related concern was expressed by R. Cutri concerning the
way the "N out of M" parameters were computed (i.e., N detections
out of M coverages). He and B. Light and J. Fowler accepted an
action item to verify proper computation in both programs.


3.) PSF Handling

    B. Light reported that the PSF table is continuing to be
filled out as more PSFs become available. One of the relatively
extreme slots was filled recently. R. Cutri requested that a plan
be developed for monitoring PSF usage and for configuration
control during the processing with 2MAPPS version 2.0.


4.) Refraction and Distortion

    H. McCallon reported that an analysis of the response of the
current POSMAN position-reconstruction algorithm to differential
refraction shows that the existing generality of the algorithm's
model is sufficient to remove refraction effects to a high degree
of accuracy. Addition of a specific refraction model is therefore
not necessary. The worst-case approximation error of the current
algorithm is 0.04 arcsec, already 2.5 times smaller than the
resolution of the PSF model, and probably too small to be reduced
further by a refraction model because of the latter's inherent
approximation error.
    It remains to be seen whether a distortion model will be
needed. If not, a considerable saving in software development
time, risk, and CPU usage would be obtained. Observations of a
field with very high astrometric quality have been taken with the
northern system, and these should be available for analysis soon.
It will take longer for similar information for the southern
system, but there is probably no rush, since it appears
impossible to include distortion models consistently throughout
2MAPPS in time for the version 2.0 delivery. This is one of the
reasons why a development pipeline is highly desirable.


5.) 2MAPPS 2.0 vs. Southern Telescope Test Support

    Many team members expressed concern about the conflict
between the deadline for 2MAPPS version 2.0 and the highly
probable need for significant IPAC involvement in quick-
turnaround analysis of southern observatory data. If the
experience with the southern observatory is similar to that with
the northern, it appears improbable that the 2MAPPS 2.0 delivery
can be made on February. R. Cutri accepted the task of obtaining
relative priorities for these activities from the project.