IPAC 2MASS Working Group Meeting #64 Minutes

IPAC 2MASS Working Group Meeting #64 Minutes, 6/13/95

Attendees: T. Conrow, R. Cutri, T. Evans, J. Fowler, T. Jarrett, D. Kirkpatrick, B. Light, S. Wheelock, J. White

AGENDA

  1. Survey Strategy Meeting
  2. EXEC/PCP Review

DISCUSSION

  1. Survey Strategy Meeting -- A Survey Strategy Meeting will be held next week at Amherst on June 21 and 22. T. Chester, R. Cutri, and H. McCallon will attend. R. Cutri requested suggestions for topics to be discussed, solutions to existing problems, corrections to existing solutions, or any other relevant matters for this meeting. H. McCallon and J. Fowler had already held discussions, and J. Fowler had issued a memo covering near-term issues affecting 2MAPPS design. Anyone with further suggestions should forward them to R. Cutri.

    A brief discussion revealed that an addition is needed to the file structure defined by H. McCallon and J. Fowler as an example of the type of data structure needing definition in 2MAPPS. Since calibration fields will also be scanned as survey strips, either an identifier for each strip will be needed to specify which kind it is, or else the strips defining calibration fields must be bookkept in a separate file. Furthermore, it cannot be assumed that a given point on the sky belongs either to one strip or is in the overlap zone of two strips; it may also belong to a calibration strip. If separate files are used for survey and calibration strips, then a similar record structure would probably be used, but probably with a larger number of non-overflow scan ID fields for the calibration strips.

  2. EXEC/PCP Review -- Next week's meeting will focus on reviewing the work done so far by T. Conrow for the EXEC/PCP subsystems. It is intended to produce a sufficient understanding of the system constraints on the subsystems so that subsystem design and coding will be able to proceed with minimal probability of any need to retrofit code for system integration. It is also intended to uncover any misunderstandings that may have occurred regarding how the system is to use the subsystems' capabilities. The goal is to achieve a two-way dialog and information exchange between T. Conrow and the rest of the team. 2MAPPS will be a multi-machine multi-CPU software system, and special considerations must be taken into account that go beyond what many of the team members have had to accomodate before.

    Topics that are clearly of interest for this review were identified so that the team could prepare questions and anticipate the sort of exchange of ideas sought. T. Conrow suggested the following questions to consider.

    1. In each subsystem, what should the system monitor keep track of?

    2. What error codes should be set for what conditions? How many different error codes should be tracked? What severity levels should be assigned?

    3. Where should error codes be tested, and what actions should be taken for specific error code values?

    4. To what extent should error recovery be attempted? For example, if a PCP fails due to running out of disk space, should EXEC attempt to restart the PCP with a different disk allocation?

    5. For each subsystem, what script does the PCP need to execute? How are parameters to be passed to the script?

    6. For each subsystem, does file locking have to be performed, and if so, which files have to be locked?

    The following points arose which the subsystem cognizant engineers must be aware of.

    1. The basic idea is that the PCP for an individual scan will execute a script for each subsystem involved. This script will be delivered with the rest of the subsystem, and should be designed so that it can operate in a subsystem test environment or an integrated system environment. The script may be as simple as a single line that invokes a program with a set of command-line parameters (probably at the very least, the name of a NAMELIST control file will have to be obtained from the command line, and possibly also information about the observation date, band ID, scan number, and perhaps more).

    2. The EXEC and PCP scripts will contain text that goes to the standard output device beginning with the characters "=== ". This will be used as a sentinel that the monitor (which will see all standard error and standard output) will recognize as appropriate for the monitor display. If a FORTRAN program needs to send such information to the monitor display, it will write to unit 6 with the sentinel characters at the beginning of the line (G. Kopan indicated after the meeting that it is not currently foreseen that FORTRAN programs will do this; such text is currently expected to be generated exclusively by the EXEC/PCP scripts).

    3. FORTRAN programs should write their error messages to the standard error device; this is done by writing to unit zero.

    4. FORTRAN programs should set the status code to an appropriate value if error terminations (and possibly also circumstances that generate warning messages) occur. This is done by halting execution via the CALL EXIT(NCODE) statement, where NCODE has the desired status code value (for warnings only, NCODE would be set only if its prior value were less than the warning code, and EXIT would not be called until an actual error or normal termination occurred).

    5. FORTRAN programs should do a certain amount of input verification; specifically, all READ statements should make use of END and ERROR branches and/or test IOSTAT and verify that the number of command-line parameters was correct.

    6. To the extent possible, misleading error messages should be prevented (e.g., from attempts to delete files that don't exist because of differences in operating environments).

    7. All programs should write their names and version numbers to the standard output device (unit 6 in FORTRAN) as soon as they begin execution; if the wrong number of command-line parameters has been passed, they should terminate with a message indicating the correct command-line syntax. In addition to other uses, this would allow all programs to be executed without command-line parameters at the beginning of a run to obtain the version information and thus verify that the path information contains no surprises (the output could even be tested by a verification utility that terminates the run if any wrong versions pop up).

    Any team members with questions about any of these points should request information from T. Conrow, J. Fowler, or G. Kopan. Some of the above will be incorporated into the coding standards section of version 3 of the FDD; J. Fowler will update that section and distribute it as an email memo.