IPAC 2MASS Working Group Meeting #104 Minutes

IPAC 2MASS Working Group Meeting #104 Minutes 9/24/96

Attendees: R. Beck, R. Cutri, T. Evans, J. Fowler, L. Fullmer, G. Kopan, H. McCallon, S. Wheelock, J. White

AGENDA

  1. Telescope Status
  2. WSDB Selection Review
  3. Guidelines for File Access and Standard Output
  4. 2MAPPS 0.1 Testing

DISCUSSION

  1. Telescope Status

    R. Cutri reported that work on the telescope optics is expected to be completed by October 15, and delivery to the observatory is scheduled for early January. The telescope slewing motors have been tested successfully. A telescope operations review is scheduled for late October.

  2. WSDB Selection Review

    R. Cutri reported that a DBMS Selection Review presentation would be held Friday at 10 AM. The criteria used in the study will be described, and a recommendation for a decision is to be made.

  3. Guidelines for File Access and Standard Output

    One of the topics that arose several times in the 2MAPPS 0.1 testing (see the next item) involved accessing files written by one subsystem from within another. Some shuffling around of file locations was found to be necessary, and this sometimes solved one problem while creating another (to uncover and resolve such things was, of course, among the primary reasons for doing the testing in the first place). J. White mentioned four methods that may be used by a subsystem to access files written by an upstream subsystem, and a fifth was suggested later by T. Conrow that will be included here. These are:

    1. copy the file from its directory to the accessing subsystem's own; not advised for large files;

    2. move the file from its directory to the accessing subsystem's own; if this is used, the file should be moved back during the accessing subsystem's termination processing, and it may be advisable to arrange for the generating subsystem to do the first move;

    3. access the file in its own directory via a relative path name; for example, a subsystem operating in the pos subdirectory can access a file in the src subdirectory (both one level down from the scan subdirectory) by appending the file name to the relative path ../src/;

    4. access the file in its own directory via an environmental variable that provides the absolute path name (see example below);

    5. access the file in its own directory via a soft link; this is essentially an alias for the full path name for the file; the alias can be a simple name that never changes inside the accessing subsystem, while the soft link is established by the wrapper script.

    Methods (1) (2), (3), and (5) will work as long as the directory structure remains unchanged, which it probably will, but otherwise some modifications may be needed. Method (4) would work in any case, because the EXEC/PCP subsystems would redefine the environmental variables if the directory structure changed, so that such changes would be transparent to the other subsystems. The environmental variables provided at this time are documented in the PCP SDS, and those involving directory names are reproduced herein as follows.

           ENVIR. VARIABLE     EXPLANATION
    |-------------------|------------------------------------
      SCRDIR             pointer to pixcal scratch directory 
      RAWDIRSFN          file with 3 (j,h,k) raw data pointers
      SCANDIR            pointer to scan tree (scan level) 
      SDATADIR           ptr to sdata dir in scan tree
      QUALDIR            ptr to qual  dir in scan tree
      FLATDIR            ptr to flat  dir  in scan tree
      OFDIR              ptr to of    dir  in scan tree
      SRCDIR             ptr to src   dir  in scan tree
      POSDIR             ptr to pos   dir  in scan tree
      IMAGEDIR           ptr to image dir  in scan tree
      EXTDDIR            ptr to extd  dir  in scan tree
      XIMGDIR            ptr to ximg  dir  in scan tree 
      PCPDIR             ptr to pcp   dir  in scan tree
    For illustration, we will include an example of how to use these to access a file in another directory whose full path is not known. This example uses functions available in our versions of Sun FORTRAN pointed out by G. Kopan and T. Evans. In this sample code fragment, it will be assumed that a program needs to open the POS01 file for band J and a scan number represented as a CHARACTER*3 variable named ScNum that is already defined. It is known that the file needed is in the POSMAN subdirectory represented by the environ- mental variable POSDIR, and the POS01 SIS states that the file name has the form ###.fpos, where is j, h, or k, and ### is the scan number. The code to open this file from another directory on (e.g.) unit 20 is as follows.

          CHARACTER*100 PthNam
C
      Call GetEnv('POSDIR',PthNam)
      Open (20, File = PthNam(1:LNBLNK(PthNam)) // '/j' // ScNum
     +                                          // '.fpos')

    The GetEnv subroutine returns the actual pathname for the POSMAN directory in the variable PthNam (e.g., '/l2/950503n/s012/pos'). The LNBLNK function returns the position of the last nonblank character in the string used as its argument, so that referencing columns 1 through last-nonblank eliminates the trailing blanks in the pathname (note that although most people have written their own functions to do what LNBLNK does, there has already been a conflict when several identically named functions were delivered to a multi- subsystem integration, so the use of LNBLNK is preferred, although one must be aware that it does not exist in every FORTRAN vendor's set of intrinsic functions or may have a different name).

    J. White also reported that EXEC/PCP "grep's" for certain "bad words" to help uncover problems, and so any casual use of these words can be misleading. He requested that such words be used when applicable and not otherwise. These words include (in case-insensitive letters): error, undefined, unknown, core, no match, no such, can't open, not found.

  4. 2MAPPS 0.1 Testing

    R. Cutri congratulated the development team for the considerable success experienced so far in the 2MAPPS 0.1 testing. The test began last Thursday, and by Friday, the processing had proceeded to the last stage of the scan pipeline, GALWORKS, where some file configuration problems led to the deci- sion to call a halt until further consultation with T. Jarrett would be possible after his return from an observing trip to Palomar. Earlier this week such work was undertaken, and progress is being made, although some files needed are still not quite ready, so total completion of the scan pipeline has not yet occurred. Some preliminary analysis of the intermediate products has been done, and as a result some changes are being made to some routines. The photometry and position reconstruction both look very good. As expected, several interface adjustments were found to be needed and have been made.

    All cognizant engineers are requested to review the output from their subsystems. The two test scans are 023 and 083 of 950503. The directories to be perused are /l2/950503n/s023 and l2/950503n/s083 and their standard subdirectories, e.g., flat, src, pos, image, and extd. A preliminary look at run times is also requested, although it is recognized that currently some debug output and other nonproduction processing is taking place.

    Once the initial flurry of redeliveries has settled down, the job of accepting nonemergency redeliveries will be done once a week. It was decided that a new 2MAPPS build will be done on Thursday mornings, after which the two test scans will be rerun. This schedule will begin about the second week of October. At that time, routine redeliveries should be made by end-of-day on Wednesdays. As part of the accepting of redeliveries, R. Beck will archive the previous versions, copy the relevant files from the /2massc/del/src and data directories, and then delete the copied files in the delivery area.