 | Data Interface Control Document | |
8
Data Interface Dictionaries
The ESO Data Interface Dictionaries (DID) include the specification of all parameters used in a particular context. A generic dictionary provides specifications that serve as a template. A specific dictionary is defined by its scope. e.g. a given instrument, observatory site, etc. In particular, there will be one Data Interface Dictionary for each instrument.
In the course of the history of a given system, e.g. an instrument, the data interface for that system my change as new keywords become necessary or modifications to old ones are made. In order to keep an archive of keywords, Data Interface Dictionaries are maintained under configuration control.
Data Interface Dictionaries are submitted for approval to the ESO DICB. The DICB maintains all dictionaries and amendments to them.
8.1 Format specification
The Data Interface Dictionary contains a DID Identification Record as the first record of the document and as many parameter description records as needed. A record is a set of lines each containing a field name and its value formatted in the following way (lines are restricted to 80 characters maximum):
<field name>: <field value>
Records are separated by one or more empty lines. Comment lines can be included if starting with a hash sign (`
#
').
- guideline-24
- When the dictionary is stored as a file on a computer system the file name should be equal to the dictionary name (see below).
8.2 DID Identification Record
The DID identification record includes the following fields:
Dictionary Name: ESO-VLT-DIC.<scope>
Scope: <scope identifier>
Source: <source identifier>
Version Control: <configuration control version number>
Revision: <version number>
Date: <YYYY-MM-DD>
Status: <release status>
Description: <free text revision history, possibly spanning more than one line>
- guideline-25
- The fields Revision, Date, Status and Description are repeated for each revision of the dictionary.
The following rules apply to the fields:
-
the dictionary name is built as
ESO-VLT-DIC.<scope>-<version>
We therefore expect to have e.g.
ESO-VLT-DIC.ISAAC-1.0
,
ESO-VLT-DIC.TEL-1.0.12
, etc.;
-
the scope identifier designates for which part of the overall data system the dictionary applies;
-
the source must be the name of the person, organization or consortium submitting the dictionary;
-
the version control number should be automatically assigned by the configuration control software. This is normally accomplished, e.g. in RCS by inserting the
$Revision: $
tag.
-
the revision number and date is assigned by the source;
-
the date in which the DID is effective is assigned by DICB;
-
the status is either
draft
,
submitted
or
released
.;
-
the description text may span over more than one line but it cannot include empty ones. It is suggested that it contains the revision history.
Example DID identification record:
Dictionary Name: ESO-VLT-DIC.GENERIC-0.9
Scope: GENERIC
Source: ESO DICB
Version Control: $Revision: 0.9.14$
Revision: 0.0
Date: 1995-10-06
Status: draft
Description: Based on GEN-SPE-ESO-19400-794/1.0
Revision: 0.9
Date: 1996-12-30
Status: submitted
Description: Reviewed by DICB members.
8.3
DID Parameter Records
Parameter records include the following fields:
Parameter Name: [<category> [<subsystem>] ]<parameter>
Class: <class identifier>[|<class identifier>]
Context: <context identifier>[|<context identifier>]
Type: <the type of the parameter>
Value Format: <format (ANSI C standard printf convention)>
Unit: <SI or derived SI units as a text string>
Comment Format: <standard comment>
Description: <free text description of this parameter, possibly spanning several lines>
The following rules apply to the fields:
-
The class can be any combination of the following separated with `
|
':
|
setup
|
keyword appears in a setup operation
|
|
header
|
keyword appears in science headers
|
|
maint-header
|
keyword appears in maintenance headers
|
|
template
|
keyword appears in a template script or signature file
|
|
conf-log
|
keyword appears in the configuration log
|
|
cond-log
|
keyword appears in the conditions log
|
|
ops-log
|
keyword appears in the operations log
|
|
reduc-log
|
keyword appears in the reduction log
|
|
config
|
keyword appears in a configuration description
|
|
private
|
keyword is used only internally by the subsystem
|
-
The context is the overall category to which the keyword belongs. Examples of contexts are
instrument
and
telescope
.
-
The type can be either
string
,
logical
(booleans),
integer
or
double
.
-
The value format defines the precision and representation of the value. For a string the precision defines the maximum length. The definition used for the ANSI-C function call
printf()
is applied for the format with the exception that the "
G
"/``
g
" option is forbidden. For booleans the value must be either
T
or
F
and the format will be
%c
.
-
The unit can take one of the values of
table 17
.
-
The comment field gives a brief description of the keyword's meaning. It can include one of the replacement tags listed in the table below
The tag gets replaced by the edited value of the keyword when the keyword is written to the header or log file.
|
Unit
Tag
|
s
|
mjd
|
deg
|
rad
|
arcmin
|
K
|
|
%TIME
|
4
|
|
|
|
|
|
|
%DAYTIM
|
4
|
4
|
|
|
|
|
|
%DEGREE
|
|
|
4
|
4
|
4
|
|
|
%HOURANG
|
|
|
4
|
4
|
4
|
|
|
%CELSIUS
|
|
|
|
|
|
4
|
-
the description field includes the semantic meaning associated to this parameter.
- guideline-26
- By convention, the comment part of the FITS/LOG/etc. record is appended the name of the physical unit in parenthesis, if applicable (see example below).
An example of a parameter record is:
Parameter Name: INS SLIT1 WIDTH
Class: setup|header
Context: Instrument
Type: double
Value Format: %.2f
Unit: arcsec
Comment Format: Width of slit 1
Description: Width of the slit in seconds of arc.
An example of a FITS header record for this keyword could then be:
HIERARCH ESO INS SLIT1 WIDTH = 2.51 / Width of slit 1 (arcsec)
Top
Back Next
Last updated: November 28, 1997
