[OPUS]

Frequently Asked Questions


What was new in OPUS 1.4?



What's New in OPUS 1.4?


How does the OPUS release 1.4 differ from OPUS 1.2?

The second CD-ROM version of OPUS corresponded to our Build 1.2, and our third release corresponds to Build 1.4. In addition to a few bug fixes, there are specific changes you should be aware of.

A number of enhancements and changes to the OPUS Observation Manager (OMG) and OPUS Process Manager (PMG) have been made over the last six months. Most of these should be transparent to you, and many of the changes will be picked up when you install the new software. However, we wanted to point out that some changes will require action on your part.

  1. To implement more rigorous checking, the syntax of OPUS path files have changed: they now require an equal sign to delimit the parameter from its value. This means you will have to edit your own path files! See 35509 below for details.

  2. To support Tru64 Unix and allow cross platform pipelines, OPUS now requires that a new subdirectory exist below the directory pointed to by OPUS_HOME_DIR and OPUS_OBSERVATIONS_DIR. See 36969 below for details.

  3. A number of changes have been made to the Observation Manager (OMG) including the capability to be more self documenting: right clicking on the cryptic stage labels will pop up an explanation. This requires changes to your pipeline stage files! The "Modify" function is now a whole lot easier and more flexible. See 34944 and 35377 below for details.

  4. The types of procedures XPOLL is capable of directly spawning has been expanded to include any executable item. This requires a change in your process resource files: the COM_FILE entries are now COMMAND entries. See 36492 below for details.


What is a PR?

A PR is a Problem Report. The problem reporting system affects all components at the Space Telescope Science Institute and includes enhancements, change requests, as well as documentation updates. Not all of the 35,000+ problem reports have been filed against OPUS!


35509: OPUS path files should use = as keyword/value separator

The routines used to parse files in OPUS have been generalized to expect to find the specified separator between keyword and value in the files being parsed (OPR.34947). In the past, one could get away with whitespace in place of the specified separator when constructing the file. To wit, path files have used space as the in-file separator even though the code specifies the character '=' as the separator. With OPR.34947, the separator specified in the code must match that used in the file; path files now require space as the keyword/value separator (the code was changed).

However, it is possible that some users may not distinguish between a space and other non-printing characters, like the tab character, when constructing path files. This will lead to a failure to initialize the path file in such cases. To eliminate this possibility, path files should be converted to use '=' as the separator and the code changed as appropriate.

!!!! CHANGES REQUIRED !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

OPUS path files, and the OPUS.ENV file, must now use '=' as the keyword/ value separator instead of space characters.

For example, the g2f_template.path file supplied with the OPUS 1.2 build had lines like:

!----------------------------------------------------------------------------
!
!  Template path for sample pipeline.  Fill in user directories to run
!  the sample pipeline.
!
!  Ver Date     Number  Author  Reason
!----------------------------------------------------------------------------
!  001 06/09/97 33428   MSwam   Create a UNIX version
!  002 11/06/97 35572   MSwam   Add STAGE_FILE
!
!----------------------------------------------------------------------------
!
!for UNIX, directory names MUST end with slash
!for ALL, variable names MUST end with colon
!
!----------------------------------------------------
! STAGE_FILE             OPUS_DEFINITIONS_DIR:g2f_pipeline.stage
!----------------------------------------------------
 STAGE_FILE             <filespec for pipeline stage file>
!
!----------------------------------------------------
! OPUS_OBSERVATIONS_DIR  /home/mswam/opus/sample/obs/
!----------------------------------------------------
 OPUS_OBSERVATIONS_DIR  <directory for OSF files>
!
!----------------------------------------------------
! gif_data              /home/mswam/opus/sample/dat/
!----------------------------------------------------
 gif_data               <directory for input GIF files for sample pipeline>
!
!----------------------------------------------------
! fits_data             /home/mswam/opus/sample/fits/
!----------------------------------------------------
 fits_data              <directory for output FITS files from sample pipeline>
======================================================================= -----> These lines MUST CHANGE to include the '=' delimiter: =======================================================================
!----------------------------------------------------------------------------
!
!  Template path for sample pipeline.  Fill in user directories to run
!  the sample pipeline.
!
!  Ver Date     Number  Author  Reason
!----------------------------------------------------------------------------
!  001 06/09/97 33428   MSwam   Create a UNIX version
!  002 11/06/97 35572   MSwam   Add STAGE_FILE
!  003 07/24/98 37263   WMiller Add = separator & rename
!
!----------------------------------------------------------------------------
!
!for UNIX, directory names MUST end with slash
!for ALL, variable names MUST end with colon
!
!----------------------------------------------------
! STAGE_FILE     =        OPUS_DEFINITIONS_DIR:g2f_pipeline.stage
!----------------------------------------------------
 STAGE_FILE      =       <filespec for pipeline stage file>
!
!----------------------------------------------------
! OPUS_OBSERVATIONS_DIR = /home/mswam/opus/sample/obs/
!----------------------------------------------------
 OPUS_OBSERVATIONS_DIR = <directory for OSF files>
!
!----------------------------------------------------
! gif_data      =       /home/mswam/opus/sample/dat/
!----------------------------------------------------
 gif_data       =       <directory for input GIF files for sample pipeline>
!
!----------------------------------------------------
! fits_data     =       /home/mswam/opus/sample/fits/
!----------------------------------------------------
 fits_data      =       <directory for output FITS files from sample pipeline>
!

Note that the OPUS.ENV file is currently a one line file:

! This is the OPUS environment file.
!
! PSF_DIR points to the environment directory.
PSF_DIR  =  OPUS_HOME_DIR:


36969: OPUS blackboard lockfile implementation

A problem with using a shared UNIX-VMS NFS device to hold an OPUS blackboard has been corrected. Lock files will now be created for all OSF and PSTAT blackboard updates in a "lock" subdirectory of the blackboard directory.

!!!! CHANGES REQUIRED !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

This REQUIRES that all blackboard directories (i.e. OPUS_OBSERVATIONS_DIR and OPUS_HOME_DIR) MUST contain a subdirectory called "lock/" (UNIX) or "[.lock]" (VMS). This subdirectory must be created before the processes are started on the blackboard. Processes will stick in a "Starting" state on the PMG display if the subdirectory is missing from OPUS_HOME_DIR. Observations will stick in their initial state on the OMG if the subdirectory is missing from OPUS_OBSERVATIONS_DIR (they will never progress beyond the creation of the OSF).

Also, a new logical under VMS is required called OPUS_HOME_DIR_LOCK. It should be defined to point to the lock subdirectory under OPUS_HOME_DIR. For example,

$    define opus_home_dir      disk$leo:[leo.mswam.g2f.home]
$    define opus_home_dir_lock disk$leo:[leo.mswam.g2f.home.lock]

No such logical is required under UNIX, nor is any OPUS_OBSERVATIONS_DIR_LOCK value required to be defined in the path.


34944: OMG changes: glob option for sorted file searches, etc.

The ability to have file searches performed in sorted order under UNIX has been implemented. By default file searches are performed in unsorted order, to get the best performance. To have file searches performed in LC_COLLATE order (usually alphabetical), set this environment variable

        setenv OPUS_SORT_FILES

in either your login shell initialization file (e.g. .cshrc) or in your opus_login.csh. This feature was requested by some sample-pipeline users when trying to adapt OPUS for their own applications.

In addition these new features are now part of the OMG.

  1. The OSF display can be filtered by the categories (counters) that appear at the bottom of the display. Using the "Select OSFs..." menu selection, you can toggle on/off the display of completed, processing, trouble, and hold OSFs. The counters always display the true counts of OSFs. They are not affected by the display filtering.

    The menu of toggle buttons can be torn-off and left "up" for constant display. Also a "FILTERED" indication will appear next to the OMG timestamp if any OSF categories are being filtered out.

  2. The "Modify" menu selection has been changed to add two new modes. The old mode, where a separate modify window is created for each selected OSF is now known as "Each Selected". It works as before.

    A new mode, "All Selected (safe)" will display a single modify window no matter how many OSFs are selected for modification. The status of the FIRST selected OSF is made available for changing. After you make A new mode, "All Selected (safe)" will display a single modify window no matter how many OSFs are selected for modification. The status of the FIRST selected OSF is made available for changing. After you make your OSF changes in the window, the changes are applied to each selected OSF that matches the status of the FIRST selected OSF. Any selected OSFs whose status does NOT match the first selected OSF are not modified, and a warning is written to the OMG log display area. This is "safe" in that if you select an OSF by mistake, it will not be modified if its status is different from the other OSFs selected.

    A new mode, "All Select (NO CHECKS)" works much like "All Selected (safe)", except that the OSF changes requested will be applied to all selected OSFs, no matter what their current status is. When using this mode just make sure that you select only the OSFs that you really want to change.

    The NO CHECKS feature can be disabled by putting this entry in the omg.dat file:

             *AllSelectedNoChecks.sensitive: 0
    

  3. The "View" menu selection now has the capability of viewing all of the ASCII files in a pipeline dataset, the FITS headers of FITS datasets (as dumped by listhead), and the FITS version of the trailer file (as dumped by listtra). When listhead and listtra are run, their output is written to a temp file created in OPUS_HOME_DIR. The temp file is deleted automatically once the display window is created (the temp file is read completely into memory).

    The keywords appearing in the omg_view.dat files have changed significantly to support the three possible view modes.

    Instead of the 2-level search hierarchy provided in the "Primary" and "Alternative" entries in omg_view.dat, there is now support for N-level search hierarchies using "Search1", "Search2", ..."Search N". You can also search several locations at the same search level.

    A selection box will be displayed when multiple qualifying files are found, to allow you to select which files to view. The selection window stays "up" until you dismiss it, allowing multiple selections to be made.

    Also a new sub-field syntax is available when using the special "<root>" entry in the omg_view.dat file. This is needed for the OTFC (on-the-fly calibration) pipeline, but might find other uses as well. The syntax is <root[x:y]> to use only a subset of characters from the OSF dataset name in creating filemasks and directory specs, where "x" and "y" are integers. (e.g. <root[1:10]> uses the first ten characters of the OSF dataset name).

    Because of the replacement of the "Primary" and "Alternative" keywords, and the new "trl", "ascii", and "fits" entries, the old omg_view.dat file WILL NO LONGER WORK. Use the new one as a template if you need an override version.

  4. The OMG now has an "Edit.Copy_to_clipboard" function like the PMG.

  5. While cleaning the OMG, a "watch" cursor will now be displayed to better indicate that work is being done.


35377: OMG enhancements

Several enhancements were made to the OMG's handling of OSF status values. The user can now click above a status value for an OSF with the 3rd mouse button to bring up a menu containing a list of all possible values with a short explanation of what that value means. Furthermore, if a value other than the present one is selected in the popup menu, that value will be modified after the user confirms the change. A similar feature was added for stage column titles (e.g., KW)-- clicking on a stage column title with the 3rd mouse button pops up the full title for that column.

The source of the information displayed in the new popup menus is the pipeline stage file for the path being monitored. The full title comes from the entries for each stage of the form:

STAGEnn.TITLE = tt

where nn is the stage number and tt is the two character stage title. Four new resources were added for the status values and their descriptions:

STAGEnn.CSTATUS.v = dddddddd
STAGEnn.PSTATUS.v = dddddddd
STAGEnn.TSTATUS.v = dddddddd
STAGEnn.NSTATUS.v = dddddddd

where nn is the stage number, v is the stage value, and dddddddd is the description of that value. For example,

STAGE03.PSTATUS.P = 'Processing observation'

Note that descriptions containing spaces should be quoted with SINGLE QUOTES (as in all OPUS resource files).

The four different resources correspond to the four states that an OSF can be in : C for complete, P for pending, T for trouble, and N for none. Each status value should be defined using one of the four resources depending on how that value should be interpreted for the purposes of tallying the number of OSF's in each state by the OMG. Categorization of stage values must be consistent across all stages (in other words, if 'P' is defined using PSTATUS for one stage, it should not be defined using one of the other resources for other stage definitions).

Each time the OMG refreshes the display, it counts the number of OSF's in each state (except none) by first looking for trouble values, then pending values, and finally complete values in each OSF. The search order is important because once a match is found, that total is incremented and the next OSF is examined. That means the precedence of categories is trouble, holding (ie., HALTed OSFs), pending then complete, so an OSF will be counted towards the total for a category with the highest precedence when it contains status values of several categories.

The user still has the capability of modifying an OSF or range of OSF's using the "Modify Selected" option in the "Manage" menu. These dialogs work the same as before except that the choices available for each stage are determined by the pipeline stage file entries-- a common list of status values for each column no longer exists.

It is important to note that the OMG is a Motif based application, so the graphical user interface conforms to the standards dictated by Motif. This has the following consequences for using these new features:


36841: The OMG needs a MANAGE/NOMANAGE switch.

A new checkbox was added to the OMG's "Select path" dialog box called "Manage". The state of this checkbox will determine whether the selected path is managed or monitored (the existing criteria that determine whether the path can be managed also apply). The initial state of the checkbox is determined by the following resource item in omg.dat (default is unchecked):

*PathDialog*ManageButton.set : 0

The default can be changed to 1 (i.e., initially checked) in omg.dat, or it can be overridden on the command line:

%omg -xrm "*PathDialog*ManageButton.set : 1"


37162: OPUS FAQ update needed - duplicate paths not allowed in OPUS_DEFINITIONS_DIR

The OPUS FAQ was updated to reflect that duplicate path files are not allowed within the OPUS_DEFINITIONS_DIR stretch.


37169: Generic tools for OTFC pipeline use

A new utility, osf_test, exists to query an OSF blackboard for OSFs meeting user-selected search criteria. OSFs meeting the search are printed by default, or the user can print selected OSF fields by providing certain OSF field keywords.

Usage: %osf_test -p pathfile
                 -f filename -t data_id -n dcf_number 
		 -c column -s status -m command -x time
                [-pr time status dataset data_id dcf_num 
		command COLUMN_NAMES]

The pathfile argument is required. All others are optional. Any OSF selection options omitted are replaced with default search characters that will match all OSFs. If the print options (-pr) are omitted, the entire OSF is printed, otherwise the selected field is printed.

Examples:

	% osf_test -p otfcal -f u2440101t

    Finds OSF under otfcal blackboard matching dataset name "u2440101t".
    Prints the entire OSF to the screen.

	% osf_test -p otfcal -c CA -s e -pr dataset data_id

    Finds OSFs under otfcal blackboard with value 'e' in the CA column.
    Prints the dataset and data_id fields of these OSFs, separated by a space,
    to the screen.

See the help page for more details.

Also, the osf_update tool no longer requires entry of a DCF_number and data_type. These fields will be left out of the OSF search if they are not supplied by the user.


36491: XPOLL file poller should allow for destruction of trigger file.

A new feature was added to all file pollers (both internal and external) whereby specifying the end state "FILE_ACTION" (either in a call to EVNT_process_opus_end() or indirectly as an XPOLL state definition as in XPOLL_STATE.07 = FILE_ACTION) spawns a process that executes the command, script, or process given in the FILE_ACTION resource file key value. The token ^f or ^F can be used to refer to the present trigger file name in this value. An optional resource file key, "FILE_ACTION_OK", also can be defined to indicate the successful return status for the command in FILE_ACTION. If this key is defined and the status returned from the command in FILE_ACTION is not equal to FILE_ACTION_OK, an error message is written to the log file. If FILE_ACTION_OK is not defined in the process resource file, no return status checking is done on the command in FILE_ACTION.

For example, in the resource file for an external poller where the goal is to delete the trigger file whenever XPOLL receives an exit status of 5, but rename the trigger file to *_BAD on exit status 3, the relevant portion of the resource file might look like:

 FILE_RANK       = 1
 FILE_DIRECTORY1 = OPUS_DEFINITIONS_DIR:
 FILE_OBJECT1    = *.DAT
 FILE_PROCESSING = _PROC
 FILE_ERROR      = _BAD
 FILE_ACTION     = '%rm ^f*'      ! ^f is replaced with current file name
 FILE_ACTION_OK  = 0              ! rm returns 0 when successful

 XPOLL_STATE.03  = FILE_ERROR
 XPOLL_STATE.05  = FILE_ACTION

The value of FILE_ACTION can be a DCL command (preceded by a $), a DCL command procedure (preceded by a @), a Unix command, or a binary executable (the executable must NOT indicate a path; instead, it should be in the path as defined by the Unix PATH environment variable or by the VAXC$PATH logical). If there are spaces in the command string of FILE_ACTION, the entire string must be enclosed in single quotes.


36492: XPOLL: Offer the option of single command execution.

The types of procedures XPOLL is capable of directly spawning has been expanded to include single DCL commands as well as binary executables; Unix versions of XPOLL similarly can spawn any executable item. The following rules apply to the value assigned to the new key COMMAND (formerly COM_FILE) in the external poller's resource file:

(VMS) - COMMAND can contain a DCL command procedure (preceded by the @ character and including a full path specification), a single DCL command (preceded by the $ character), or a VMS image (only the file name- no path specification; the image must be in the path as specified by the logical VAXC$PATH).

Examples-

     (DCL command procedure) COMMAND = @OPUS_DEFINITIONS_DIR:WCS_NIC.COM

     (DCL command)           COMMAND = '$dir disk$data:[my_data]'

     (VMS Image)             COMMAND = 'MY_PROGRAM.EXE ARG1 ARG2 ARG3'

(UNIX) - COMMAND can contain any shell command, shell script or binary executable. Shell scripts and executables should NOT include a path- the file must be in the login shell's PATH.

Examples-

     COMMAND = 'ls -l /data/my_data'

     COMMAND = my_script

     COMMAND = 'my_program arg1 arg2 arg3'

*** NOTE: if the value of COMMAND contains spaces, the entire string must be enclosed in single quotes.


36493: pmg_restrictions.dat should work as advertised.

Problems with character case in pmg_restrictions.dat have been corrected. The contents of this file are constructed as follows:

This file is used to restrict the number of copies of certain processes that the PMG is allowed to start up. Certain requirements dictate that only one copy of a process be allowed to run, so this file is a flexible method for enforcing that behavior through the PMG.

The syntax of entries is:

 PROCESS.PATH.NODE = NUM_COPIES (case insensitive)

    where PROCESS    = name of pipeline process (same as resource filename)
          PATH       = name of the path in which the restriction occurs
          NODE       = name of the machine on which the restriction occurs
          NUM_COPIES = number of copies of the process allowed

    The "*" wildcard entry is allowed for the PATH and NODE components.

Some examples:

gifin.g2f.orchid = 2     ! maximum of 2 copies of gifin running in path g2f
                         ! on node orchid
dp_new.*.* = 1           ! only one copy of DP_NEW across all paths and nodes
PI_MAIN.*.AREA51 = 1     ! only one copy of PI_MAIN on area51 at a time


36544: Enhance "glob" error reporting in OSFILE pkg

The current calls to the UNIX function "glob" in the OSFILE_PKG report a generic error message for any error other than "no match". The code should report specific error messages for the known possible errors, as listed in the glob.h header file. This will inform the user when glob is not supported on the host operating system, as well as other possible error conditions.


36600: Modify the PMG's Select Paths dialog box.

The PMG's Set Paths menu now can be torn-off by selecting the dashed line. A torn-off menu stays open until explicitly closed, and the menu can be relocated on the screen. A "Toggle All" button was added to this menu that toggles the value of all paths when selected. A condition where the PMG's Process Selection Dialog Open or Save pipeline file dialogs could be prevented from reappearing on the screen if they were up when the Cancel button was pressed in the Process Selection dialog has been resolved.


Top of What's New FAQ

Top of OPUS FAQ