IPAC 2MASS Working Group Meeting Minutes, #56

IPAC 2MASS Working Group Meeting #56 Minutes, 2/28/95

ATTENDEES

T.Conrow, D.Egret, T.Evans, J.Fowler, L.Fullmer, T.Jarrett, G.Kopan, B.Light, M.Moshir, S.Wheelock, J.White

AGENDA

  1. Sample DENIS Data
  2. EXEC/PCP Prototype Demo
  3. New APM Match Program
  4. New Version of Simulator
NOTE: Last week's meeting was cancelled because of last-minute problems with the perl demo.

DISCUSSION

  1. Sample DENIS Data -- D. Egret described some sample DENIS data that should be of interest to 2MASS. Four scans are here at IPAC, comprising scans in J and K over two strips of sky. The DENIS observing method involves 256x256 arrays covering 12'x12' fields of view, with each basic field integrated several times with a local dithering pattern to improve sampling, and a 2' overlap field-to-field in the scan direction (declination). Each scan is composed of 180 frames.

    Problems with the data are similar to some we have had: there are some dead pixel rows, and the reset decay pattern yields a bias error similar to what we have seen. Some difficulty was experienced in finding disk space in which to load the data from tape. M. Moshir had already taken some first looks at part of one scan, and he and T. Jarrett agreed to pursue the task of getting at least 3-10% of the frames loaded on disk for analysis, with the rest to follow as soon as more disk space could be made available.

  2. EXEC/PCP Prototype Demo -- T. Conrow described the prototype code he has written in support of the design of the EXEC and PCP subsystems. This code employs perl to launch and monitor clients and servers on several machines. The demo of this code uses four machines to run ten tasks. The basic task is a c-shell script that downloads some protocam data and runs KAMPhot on it. One machine serves as a base of operations, but this can be any machine. From this machine, perl-script servers are launched on all machines, and each of these servers clones itself a specified number of times to process the list of tasks to be performed.

    For each server, a client is launched on the base machine, and the client/server pairs set up and open sockets for communication across the network. A run file contains the task list and information about which machines are to be used, the number of servers to be set up on each machine, etc. In 2MAPPS, the run file would be created for each observation date by the TAPELOAD subsystem, based on information obtained from the file headers.

    The clients are capable of locking the run file, selecting a task on the list, updating the file to indicate the task has been taken, and then unlocking the file for other clients to process in the same fashion. When a client takes a task, it sends information to its server with which the server runs KAMPhot to accomplish the task. Running KAMPhot serves as a sample subtask launched by the server; there is great flexibility in the actual subtasks that can be be launched. When a server finishes its task, it notifies its client, which logs out the task and gets another, unless there are no more tasks to be done, in which case the client/server pairs shut themselves down.

    A separately launched monitor program can query the servers for status and generate a display and handle alarms. For FORTRAN programs to generate messages most easily incorporated into this monitor capability, the messages should be written to the stderr device, which in FORTRAN is available by writing to unit number zero.

    After the meeting, a demo of this capability was executed in T. Conrow's office. This demo proceeded smoothly from start to finish, with only some cleaning up left to be done by hand because it has not yet been automated, but is expected to be made automatic later.

  3. New APM Match Program -- T. Evans announced that a new APM match utility has been completed and that an email message would be issued soon describing this new program.

  4. New Version of Simulator -- B. Light announced that a new version of the simulator has been produced. This version simulates dead pixels by employing a mask file. It is capable of using the mask file produced by CFlat, and simulations using the CFlat mask from 94-06-01 scans will be performed. Runs using the mask input to CFlat in the 94-06-01 runs have already been made (about 0.5% of the pixels masked off), and the effect of the dead pixels on photometry in this case are negligible compared to the impact of the known subpixel response variations.