Parameter records include the following fields:
Parameter Name: [< ategory> [<subsystem>℄ ℄<parameter> Class: < lass identifier>[|< lass identifier>℄ Context: < ontext identifier>[|< ontext identifier>℄ Type: <the type of the parameter>
Value Format: <format (ANSI C standard printf onvention)> Unit: <SI or derived SI units as a text string> Comment Format: <standard omment>
Des ription: <free text des ription of this parameter, possibly spanning several lines>
The following rules apply to the fields:
• The subsystem and parameter elements of the parameter name may contain a suffixi, which
is a placeholder for an integer describing multi-dimensional subsystems or parameters.
• The class can be any combination of the following separated with ‘|’:
setup keyword appears in a setup operation header keyword appears in science headers prim-header keyword appears in a primary header unit ext-header keyword appears in an extension header unit maint-header keyword appears in maintenance headers
template keyword appears in a template script or signature file onf-log keyword appears in the configuration log
ond-log keyword appears in the conditions log ops-log keyword appears in the operations log redu -log keyword appears in the reduction log q -log keyword appears in the quality control log onfig 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, for examplesinstrumentor teles ope.
• The type can be eitherstring,logi al(Booleans),integerordouble.
• The value format defines the precision and representation of the value. For a string the pre- cision defines the maximum length. The definition used for the ANSI-C function callprintf()
is applied for the format, with the exception that the"G"/"g"option is forbidden. For Boolean
keywords the value must be eitherTorFand the format will be% .
It is strongly recommended that precision be explicitly specified for all floating point keywords (e.g.%.3ffor values with three significant digits instead of generic%f).
Data Interface Control Document
GEN-SPE-ESO-19400-0794
Date 8 July 2011 Issue 5 Page: 66 of 84
• The unit can take one of the values described in Chapter 8 on p. 68.
• 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
Unit
Tag s mjd deg rad ar min K
%TIME •
%DAYTIM • •
%DEGREE • • •
%HOURANG • • •
%CELSIUS •
The tag gets replaced by the edited value of the keyword when the keyword is written to the header or log file.
To increase human readability, the comment field may contain unit abbreviation enclosed in square brackets. The abbreviation should follow convention described in Chapter 8 on p. 68. The unit stored in the comment should not be used by software; if it is necessary to specify the unit of any given quantity, then a separate keyword with parameterUNITmust be used.
• The fieldComment Format:may also be namedComment Field:.
• The description field includes the semantic meaning associated to this parameter.
All dictionaries must contain a parameter record describing the dictionary itself. It should look as follows:
Parameter Name: < ategory> DID
Class: <whatever is appli able> Context: < ontext identifier>
Type: string
Value Format: %30s Unit:
Comment Format: Data di tionary of < ategory>
Des ription: Name-version of ESO DID to whi h < ategory> keywords omply
The class should comprise the classes of all keywords defined in the dictionary. Accordingly, the keyword itself should be written to all subsystems described by the classes.
For example, theDIDkeyword describing thePRO dictionary release 1.14 is calledPRO DID and
It is written to the FITS header of all pipeline products (Class = header).
If applicable, the comment part of the FITS/LOG/etc. record should contain the name of the physical unit in parentheses (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: ar se
Comment Format: Width of slit 1 [ar se ℄
Des ription: Width of the slit in se onds of ar .
A FITS header record for this keyword would be:
Chapter 8
Physical Units
Per IAU recommendation, physical units used in a DID must comply with basic or derived (i.e. using accepted prefixes) SI units. Exceptions are allowed for special units which are more convenient for astronomy. It is also allowed to utilise commonly used units for engineering parameters (e.g. liters per minute for flow, etc.).
Table 8.1: Physical units allowed for ESO DIDs
Quantity Unit String Meaning or use
SI base & supplementary units
length m meter
mass kg kilogram
time s second of time
plane angle rad radian
solid angle sr steradian
temperature K kelvin
electric current A ampere
IAU-recognised derived units
frequency Hz hertz
energy J joule
electric potential V volt
force N newton
pressure, stress Pa pascal
Additional units allowed position or plane angles deg degrees of arc
dimension on the sky ar min minutes of arc
offsets on the sky ar se seconds of arc
magnitude mag magnitude (at given wavelength)
flux Jy jansky (10
−26W m−2Hz−1)
wavenumber m^-1 wavenumber (used in interferometry)
angular spatial frequency ar se ^-1 UV plane parameter (used in interferometry)
temperature C centigrade (degrees celsius)
pixel pixelorpix pixel
unit of A/D converter adu unit of A/D converter
encoder unit En Encoder unit
For units not covered in Table 8.1 abbreviations specified in [AD10] must be used.
Naming convention for optical
components
This section describes how optical components in use at the VLT telescopes are named and identi- fied.
Such identifiers are used:
• by astronomers when selecting a particular observing configuration;
• by operations staff when setting up the requested optical elements for the upcoming night;
• by operations staff when operating instruments and performing service observations;
• by VCS when writing FITS keywords into the data headers;
• by pipeline software when performing standard data reduction;
• by astronomers when reducing data off-line;
• by archive users who prepare archive research programmes.
Astronomers are likely to use names while observatory staff will mostly use identifiers. The con- vention described in this section was developed with the aim of facilitating all of the tasks mentioned above while at the same time maintaining the discipline needed in order to handle the few hundred elements that will be used at the VLT.
This naming convention will be applied to all VLT instruments.
9.1
Identification scheme
Each optical element, i.e. filters, grisms, etc., in use at any VLT, NTT or other VLT compliant instru- ments shall have a unique identifier and a verbose name.
Verbose names are recorded in the keyword NAME(e.g. FILT NAME,GRIS NAME orOPTIi NAME)
and follow the scheme described in Section 9.3.
Data Interface Control Document
GEN-SPE-ESO-19400-0794
Date 8 July 2011 Issue 5 Page: 70 of 84
Identifiers are typically sequential numbers which are given to each element when acquired. These identifiers are recorded in the keyword ID, e.g. FILT ID, GRIS ID or OPTIi ID (see Sec-
tion 4.4.2 on page 44 for more details). TheIDserves as the reference to the full characterisation
file (e.g. transmission and efficiency curves of filters and grisms etc.) which is the authoritative source of information for each component.
The identifier serves as unique label for each individual piece of hardware. For example, the observatory utilises several K filters; all observations with any of these filters will haveFILT NAME
set to'K'withFILT IDidentifying the specific physical filter used.
Identifiers of elements that cease to exist (e.g. a broken filter) shall be retained in order to ensure the historical validity of the Science Archive.
Instrument Consortia preparing Data Interface Dictionaries must foresee at least 10 characters space for theIDkeywords and 30 characters for theNAMEkeywords.