Section 13. CDBS Control Relations and Tables

13.1 CDBS Design

During 1996 CDBS underwent a major redesign. The new simplified structure was put in place in February 1997. The new design increases the level of automation in the delivery process and permits more detailed tracking. It also accommodates the new instruments, STIS and NICMOS, with their new file structures and naming conventions. Each instrument now has two relations, known as the file-level relation and the row-level relation. These have names like acs\_file and acs\_row. The relations are linked by having matching values for file name and expansion number.

Table 13-1. File-Level Relation

Field	Format
file_name	varchar(50)
expansion_number	integer
delivery_number	Integer
reference_file_type	varchar(50)
useafter_date	datetime
opus_flag	char(1)
comment	text
general_availability_date	datetime
opus_load_date	datetime
archive_date	datetime
reject_flag	char(1)
reject_delivery_number	integer
reject_by_file_name	varchar(50)
reject_by_expansion_number	integer
comparison_file_name	varchar(50)

Table 13-2. Row-Level Relation

Field	Format
file_name	varchar(50)
pedigree	varchar(50)
observation_begin_date	datetime
observation_end_date	atetime
observation_mode	multiple fields
equivalence_class	multiple fields
expansion_number	integer
comment	text

Whenever a calibration image is installed, a row is added to the file-level relation and to the ro-level relation.

When a table is installed, a row is still added to the file-level, but a number of row-level entries may be made, one for each instrument mode covered.

When a delivery is made, the general\_availability\_date is set. The files are delivered to OPUS and in parallel to DADS; this is done automatically by the CDBS Pipeline. OPUS receives two more files, an SQL command file and a catalog. The SQL commands will be run to install in OPUS a version of the CDBS update. The catalog lists the files to be added to the set of files maintained by OPUS to service the pipeline. The catalog also lists any files that may be deleted because they are superseded by the new delivery. When OPUS has updated its data base, an e-mail message is sent to a predefined CDBS directory. The message is detected automatically and causes the opus\_load\_date to be set. Similarly, a message from DADS automatically sets the archive\_date.

13.2 Load Files

A special file known as the load file (generated with the mkload task) accompanies every delivered calibration file. It is largely derived from the header of the file and therefore has matching values of all the configuration keywords and useafter\_date. The values of opus\_flag and level\_of\_change must be set by the deliverer. The name of the comparison file is automatically generated from what seems to be the best match but may be altered by the person delivering the files. A file-level comment must be supplied, and row-level comments may be supplied.

When mkload runs, it also checks to see if any of the keyword values going into the .lod file contain one of the “wildcard sentinel” values. This is done directly in the mkload code itself, not afterwards. The wildcards are listed in a file used by the mkload code and are also in the ###.rule files where ### is the instrument name. The wildcard sentinel list is currently:

../../inc/config.h:#define  WILDCARD_LIST
  "-1|any|-1.|abcdall|single_amp|fullframe_4amp|fullframe_2amp|
  custom_subarrays|chip1_sub_nocorners|chip2_sub_nocorners|quad_corner_subarrays"

If any one of those values is found in a keyword, and the keyword is NOT one of these:

change_level|pedigree|observation_begin_date|observation_end_date|expansion_number|comment

then the load file is marked as needing expansion and the code will automatically put an entry into the

.lod file for each expanded keyword value, as given in the appropriate ###.rule file.

Table 13-3. Load File

Field	Format
Header	Header
file_name	varchar(50)
instrument	varchar(50)
reference_file_type	varchar(50)
useafter_date	datetime
comparison_file_name	varchar(50)
opus_flag	char(1)
comment (file-level)	text

Table 13-3. Load File

Field	Format
Detail	Detail
level_of_change	varchar(30)
pedigree	varchar(50)
observation_begin_date	datetime
observation_end_date	datetime
observation_mode	multiple
comment (row-level)	text

The load file is used to generate the SQL commands that load the CDBS relations and is then discarded. It may be regenerated from the data base in order to edit the comments if further information becomes available. This is done without extracting or in any way changing the calibration files themselves.

13.3 Synphot Relations

The relations to support pysynphot/Synphot are almost identical to the file and row relations given above. Pysynphoti/Synphot is used by all instruments and is treated like another instrument. There are synphot\_file and synphot\_row relations.

Table 13-4. Synphot_File Relation

Field	Format
file_name	varchar(50)
expansion_number	int
delivery_number	int
reference_file_type	varchar(50)
useafter_date	datetime
opus_flag	char
comment	text
general_availability_date	datetime
opus_load_date	datetime
archive_date	datetime
reject_flag	char
reject_delivery_number	int
reject_by_file_name	varchar(50)
reject_by_expansion	number
comparison_file_name	int

Table 13-5. Synphot_Row Relation

Field	Format
file_name	varchar(50)
expansion_number	int
delivery_number	int
compname	varchar(50)
equivalence_class_severe	int
equivalence_class_moderate	int
pedigree	varchar(50)
observation_begin_date	datetime
observation_end_date	datetime
comment	text