OTFC Design for Getref and Upref

Summary

The geterf and upref tasks will need to be updated in order to support on the fly calibration. The most significant changes are:

Getref

Getref operates in two modes: summary and detail mode. The summary mode currently returns the name of the best reference files for an observation set and the detail mode returns information about an individual file. The detail mode will not be changed by the new version of getref and so will not be discussed further.

Getref currently does a query of the dads database to get the best reference files and the reference files originally used to process the observation. It loops over observation name, allowing a single run of the task to produce results for multiple observation sets. It determines which instrument was used for an observation from the instrument code in the observation set name and gets the names tables and columns to query from arrays hardwired into the program. These arrays can be found in the file global.h. The query is straightforward, based only on the observation set name. The results include the observation set name, the keyword name (also read from global.h), the best reference file, and the original reference file.

The new version of getref will query two additional database tables to return to retrieve the calibration switches and keyword changes. Since the structure of these tables have not been finalized, I cannot specify the query that will be used to search them, but it should be no more complicated than the current search, i.e., a select based on the observation set name. There will be a locking mechanism for all three of the database tables that will be queried. Getref will check to see if a lock exists before querying for an observation set. If a lock is found, a warning message will be printed and the observation set will be skipped. On exit, a non-zero error status will be set (exact value is TBD) so that scripts calling getref can check for this condition. The ouput of getref will include the observation set name, header keyword name, header keyword value, and requested change (none, update, insert, or delete). The first three columns are identical with the current output of getref, the fourth column replaces the original reference file name in the output.

The information for the output comes from the following sources:

One unresolved issue is how the requested change field should be filled in for reference file names. There are some cases where this field should be insert, meaning a new keyword will be inserted if it is not already in the header, and some cases where this field should be update, meaning a keyword will not be inserted if the field is not already in the header. But there is no way to set this field based on current information in the database.

Upref

Upref reads the output file created by getref and uses it to update the reference file header. All keywords are assumed to be in the primary header. The program runs in two modes: verify mode, where the user is asked to verify any changes before they are made, and no verify mode, wher changes are made without user input. Upref currently has an input parameter that conatains a list of extensions which are used when looking for the image to modify.

Upref also has a set of rules for adding a directory name to the reference file names in the input file. It looks at the first letter of the extension to see if the reference file is a fits file (it should be "f") or geis image (it should be "r" or "b"). Otherwise it assumes it is a table. Then it extracts the instrument letter from the reference file name and uses it to build the logical directory name (_ref$ for images and _tab$ for tables.) The instrument letter is the character preceding the last underscore if the file is a fits file, it is the last character of the name if the file is a geis image, and it is the middle letter of the extension if the file is a table.

Upref currently reads the header of the image that is going to be modified, compares the value stored in the header to that in the file, and does not make any modification if the two values are the same. This is to reduce the number of questions to the user if the task is run interactively. All changes in the file are currently treated as if insert chnages or update changes depending on the value of the task parameter addkey. There is no provision for deletions in the current version.

The new version of upref will choose the extension of the image based on a hardwired array indexed by instrument rather than by task parameter. It also will use the new column in the file it is passed by getref to decide whether to insert, update or delete the keyword. Other than these changes, the task will be unchanged.


Back to index of cdbs tasks.