IPAC 2MASS Working Group Meeting Minutes, #55

IPAC 2MASS Working Group Meeting #55 Minutes, 2/14/95


T.Conrow, R.Cutri, T.Evans, J.Fowler, T.Jarrett, D.Kirkpatrick, G.Kopan, J.White


  1. Schedules
  2. EXEC and PCP
  3. Next Protocam Run


  1. Schedules -- J. Fowler announced that a new revision of the 2MAPPS development schedule exists, and will be distributed to Working Group members after the meeting. Also, next week's meeting (21 February) may be cancelled or may take place in the Garden of IPAC, depending on weather and urgency. We were bumped out of the Large Conference Room by the Upstairs Science Steering Committee (of course ISO bumped us out of the Small Conference Room long ago). It is also possible that we will simply meet in the computer room, where we can observe the perl demo discussed in the next item. J. Fowler will distribute an email message to the Working Group members on Monday, 20 February, to give last-minute plans.

  2. EXEC and PCP -- T. Conrow announced that the perl demonstration discussed two weeks ago has run successfully to the extent planned, but that more ambitious processing is really needed to simulate the process communication implied in the 2MAPPS FDD. He will pursue this further and expects to have results in time to report next week. He pointed out that perl has its own file I/O and can do the reading, writing, and file locking needed for PCPs to assign themselves scans to process. He has also been looking at PVM (Parallel Virtual MAchines) as an alternative to perl for implementing the EXEC and PCP subsystems. PVM provides parallel-process communication capabilities that FORTRAN and C programs can access. A PVM daemon runs on each virtual machine and can launch and terminate other daemons through which the FORTRAN and C programs can communicate with each other. PVM appears capable of doing the job needed by 2MAPPS but has a couple of disadvantages that will probably result in our abandoning it: (a.) it seems to limit the flexibility with which shell scripts can be used, requiring them to be executed via system calls from the FORTRAN or C programs and thereby turning the hierarchy upside down; (b.) it is really designed to handle much more tightly interwoven tasks, and the documentation describes much more capability than we need and have time to sift through. Since perl appears viable, and since we do not have time to investigate all possible approaches exhaustively, we will probably have to commit to something too soon for PVM to remain an option.

  3. Next Protocam Run -- R. Cutri reported that the next protocam run will be from 17 April to 7 May. This is a little later than we had expected, but we must still be prepared for a large amount of data to start showing up before the end of April. The telescope vendor has been selected and is expected to provide a telescope about six months ahead of the schedule assumed up until now. The survey probably won't start much sooner than we have been expecting, but pre-survey data may be available sooner and in larger amounts than previously anticipated.