This appendix describes the syntax of HST data file names, which encode a large amount of information about the files themselves. Datasets retrieved from the Archive as described in Chapter 1 consist of multiple files in FITS format, each with a name that looks like this:
In order to use IRAF/STSDAS tasks to work with data from instruments other than NICMOS and STIS, you will want to convert these FITS files into GEIS format. See page 2-11 for instructions on how to convert FITS files to GEIS files using strfits. Like FITS files, the names of GEIS files also derive from a file's rootname and suffix, and they look like this:
ipppssoot.sfxGenerally the suffixes of GEIS files end either in "d", indicating a binary data file, or "h", indicating an ASCII header file. The two GEIS files x3l80101t_d0h and x3l80101t_d0d together contain the same information as the single FITS file x3l80101t_d0f.fits.
The identifier referred to here as a "suffix" has often been called an "extension" in the past. However, the individual pieces of FITS files are also known as "extensions" (see "Working with FITS Image Extensions" on page 2-4). For clarity, this handbook will use the term "extension" when refering to a component of a FITS file and the term "suffix" when referring to the three character identifier in a filename.
IPPPSSOOT Root File Names
Instrument used, will be one of:
V - High Speed Photometer
Program ID; can be any combination of letters or numbers (46,656 combinations possible). There is a unique association between program ID and proposal ID.
Observation set ID; any combination of letters or numbers (1,296 possible combinations).
Observation ID; any combination of letters or numbers (1,296 possible combinations).
Source of transmission or association product number
Suffixes of Files Common to all Instruments
The three-character suffix of a data file (e.g., d0h) identifies the type of data that a file contains. Because the meanings of these suffixes change from instrument to instrument, please refer to the appropriate instrument-specific Data Structures chapter for their definitions. Several types of file suffixes are, however, common to all instruments.
Observatory Monitoring System (OMS) files, having suffixes cm* or ji*, contain Observation Logs describing how the HST spacecraft behaved during a given observation. OMS headers, which you can read with the IRAF task imheader (see "Working with GEIS Files" on page 2-11), are divided into groups of keywords that deal with particular topics such as SPACECRAFT DATA, BACKGROUND LIGHT, POINTING CONTROL DATA, and LINE OF SIGHT JITTER SUMMARY. The headers themselves provide short descriptions of each keyword.OMS tables and images record spacecraft pointing information as a function of time. For more information on OMS files, you can consult Appendix C or the STScI Observation Logs WWW pages at:
The suffix ocx denotes Observer Comment Files-OCX files-which are produced by STScI personnel to document the results of real-time commanding or monitoring of the observation, along with keywords and comments. Prior to April 17, 1992, OCX files were not always archived separately and, in some cases, were prepended to the trailer file.
Trailer files (suffix trl) are FITS ASCII tables that log the processing of your data by the OPUS pipeline.
Note that trailer files are formatted with 132 columns.
The STIS and NICMOS calibration pipelines sometimes produce single calibrated images from associations of many exposures. These associations allow HST pipeline processing to proceed further than it has in the past. For example, a NICMOS observer might specify a dithering pattern in a Phase II proposal. NICMOS would then take several exposures at offset positions, and the pipeline would combine them into a single mosaic. In this case, the original set of exposures constitutes the association, and the mosaic is the association product. Similarly, a STIS observer might specify a CR-SPLIT sequence in a Phase II proposal. STIS would gather several exposures at the same pointing, and the STIS pipeline would process this association of exposures into single image, free of cosmic rays, that would be the association product.
In practice, STIS and NICMOS store the exposures belonging to associations differently. The exposures belonging to a STIS association all reside in the same file, while the exposures belonging to a NICMOS association reside in separate datasets. See the relevant Data Structures chapters for more details.
Figure B.1: Association Results Screen from StarView