- 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.
- 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.
- 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.