OGIP Calibration Memo OGIP/93-012

Glossary of Keywords commonly used in OGIP FITS Files

Ian M George, Lorella Angelini and Mike Corcoran

Code 668,
NASA/GSFC,
Greenbelt,
MD 20771

Version: 1995 Jan 27
(by IMG)

SUMMARY

This document is the first attempt to keep track on the names and usage of keywords commonly required in OGIP FITS files.

This draft is extremely provisional & incomplete

Contents

• SUMMARY
• LOG OF SIGNIFICANT CHANGES
• INTRODUCTION
  • How to Supply Updates
• MANDATORY & RESERVED KEYWORDS IN THE NOST STANDARD
  • Mandatory Keywords
  • Other keywords reserved in the NOST standard
• RESERVED KEYWORDS LIKELY TO ENTER THE NOST STANDARD
  • The World Coordinate Sytem proposal of Griesen & Calabretta
• EXTENSION/FORMAT IDENTIFICATION
• MISSION/INSTRUMENT RELATED
  • General
• OBSERVATION/TARGET RELATED
  • Observation
  • Target Details
  • Related Instrument-Specific Keywords
• DATA PROCESSING, PIPELINE etc
  • Related Instrument-Specific Keywords
• SPECIFICATION OF PHYSICAL COORDINATES
  • Celestial
  • Harder stuff
• SPECIFICATION OF TIME
  • General exposure times etc
  • Absolute Times
  • Corrections to Times
• IMAGES
  • General
  • Calibration-Related
• SPECTRA
  • General
• OTHER
• USEFUL LINKS TO OTHER HTML PAGES
• Index
• About this document ...

LOG OF SIGNIFICANT CHANGES

Release	Sections Changed	Brief Notes
Date
1994 Feb 28		First (internal) Draft
1995 Jan 27	All	Made compatible with LaTeX2HTML software

INTRODUCTION

... section incomplete

How to Supply Updates

The master copy of this document is written in LaTeX, with the ASCII-source structured as follows:

{\bf KEYWORD}\index{Updates}\\
This is where the definition goes. There is no formal limit on it's length,
but attempts should be made to be concise. Links to other documents are
encouraged.\\
{\it Allowed values:}
	Note any limitations on the value of the keyword
	(or reference/link to) the appropriate document\\
{\it First Used/Defined by}:
	Note the origin of the keyword (if known) and/or reference/link to
	the appropriate document\\
{\it Within the OGIP:}
	Note any limitations/points-to-note etc regarding the use of the
	keyword \\
{\it See Also:}
	Note (and link to) other related keywords.

giving rise to output of the form:

KEYWORD
This is where the definition goes. There is no formal limit on it's length, but attempts should be made to be concise. Links to other documents are encouraged.
Allowed values: Note any limitations on the value of the keyword (or reference/link to) the appropriate document
First Used/Defined by: Note the origin of the keyword (if known) and/or reference/link to the appropriate document
Within the OGIP: Note any limitations/points-to-note etc regarding the use of the keyword
See Also: Note (and link to) other related keywords.

Thus, it would greatly help the installation of new keywords, or corrections to the existing definitions/information if this structure was kept in mind. Indeed,

MANDATORY & RESERVED KEYWORDS IN THE NOST STANDARD

In this section we list the keyword mandatory or reserved by the NOST standard. For completeness all such keywords are listed along with their definitions blatently plagiarized from the NOST documentation. However in a few cases additional information/guidelines specific to the OGIP is included.

Mandatory Keywords

SIMPLE
The value field shall contain a logical constant denoting whether the file conforms to the NOST standard. This keyword is mandatory only for the primary header, but must be the first keyword in that header.
Allowed values:

• T signifying that the file conforms tp the NOST standard
• F signifying that the file does not conform to the NOST standard in some significant way.
  

First Used/Defined by: NOST standard
Within the OGIP: all files should conform to the NOST standard.

BITPIX
The value field shall contain an integer specifying the number of bits used to represent a data value. This keyword is required in both primary and extension headers, and must be the second keyword in each header.
Allowed values: Given in the NOST standard document
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints

NAXIS
The value field shall contain a positive integer no greater than 999 representing the number of axes in an ordinary data array. A value of zero indicates that no data follows the header of the HDU. This keyword is required in both primary and extension headers, and must be the third keyword in each.
Allowed values: An integer in the range 0 - 999
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints

NAXISnnn
The value field of this indexed keyword shall contain a positive integer representing the number of positions along axis nnn of an ordinary data array. The NAXISnnn must be present for all values of nnn from 1 to the value given by the NAXIS keyword. These keywords are required in both primary and extension headers, starting with NAXIS1 as the fourth keyword in each header A value of zero for any of the NAXISnnn signifies that no data follow the data in the HDU. If the value of the NAXIS keyword is equal to zero, there should not be any NAXISnnn keywords.
Allowed values: 0, or any positive integer as described above
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints
See Also: NAXIS (Section 2.1)

END
This keyword has no associated value and is used to indicate the end of the the Header of the HDU.
Allowed values: Columns 9-80 must be filled with ASCII blanks.
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints

EXTEND
The value field shall contain a logical constant denoting whether the file may contain extensions. This keyword must appear immediately after the last NAXISnnn keyword, or, if NAXIS=0, immediately after the NAXIS keyword.
Allowed values:

• T signifying that the file may (but do not have to) have extensions present
• F signifying that the file cannot have any extensions.

First Used/Defined by: NOST standard
Within the OGIP: it is recommended that all files have the value T.
See Also: NAXIS & NAXISnnn (Section 2.1)

XTENSION
The value field shall contain a character string giving the name of the extension type. This keyword is mandatory for the header of an extension, and must be the first keyword in that header. This keyword must not appear in the primary header.
Allowed values: Given in the NOST standard document
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints

PCOUNT
The value field shall contain an integer used to specify the data structure DEFINITION INCOMPLETE ... needs to be more specific - Bill ?
Allowed values: Given in the NOST standard document
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints

GCOUNT
The value field shall contain an integer used to specify the data structure DEFINITION INCOMPLETE ... needs to be more specific - Bill ?
Allowed values: Given in the NOST standard document
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints

Other keywords reserved in the NOST standard

The keywords in this section are optional, but may only be used as defined by the NOST standard (as summarized here).

DATE
The value field shall contain a character string giving the date on which the HDU was created. Specification of the date using Universal Time is recommended.
Allowed values: The syntax MUST conform to DD/MM/YY, where DD is the day, MM is the month, and YY is the last two digits of the year.
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints

ORIGIN
The value field shall contain a character string identifying the organization creating the FITS file.
Allowed values: No constraints
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints

BLOCKED
This keyword may be used only in Primary Headers.It must appear within the first 36 keywords, and its presence with the required logical value T advises that the physical block size of the FITS file in which it appears may be an integral multiple of the logical record length, and not necessarily equal to it. However the physical block size and logical record length may be equal even if this keyword is present or unequal if it is absent (!) It is reserved primarily to prevent its use with other meanings (!!) The use of this keyword is deprecated in the NOST standard.
Allowed values: No constraints
First Used/Defined by: NOST standard - but now deprecated
Within the OGIP: This keyword should not be used.

Keywords describing observations

DATE-OBS
The value field shall contain a character string giving the day on which the observations stored within the array were made. Specification of the date using Universal Time is recommended.
Allowed values: The syntax MUST conform to DD/MM/YY, where DD is the day, MM is the month, and YY is the last two digits of the year.
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints

TELESCOP
The value field shall contain a character string identifying the telescope used to aquire the data contained in the array.
Allowed values: No formal constraints imposed by NOST, but additional constraints imposed within the OGIP.
First Used/Defined by: NOST standard
Within the OGIP: This keyword should be used to specify the mission/satellite used to aquire the data, and the values must conform to those given in OGIP/93-013

INSTRUME
The value field shall contain a character string identifying the instrument used to aquire the data contained in the array.
Allowed values: No formal constraints imposed by NOST, but additional constraints imposed within the OGIP.
First Used/Defined by: NOST standard
Within the OGIP: This keyword should be used to specify the detector used to aquire the data, and the values must conform to those given in OGIP/93-013

OBSERVER
The value field shall contain a character string identifying who acquired the data associated with the header.
Allowed values: No formal constraints imposed by NOST, but additional constraints imposed within the OGIP.
First Used/Defined by: NOST standard
Within the OGIP: SECTION INCOMPLETE

OBJECT
The value field shall contain a character string giving the name of the object observed.
Allowed values: No formal constraints imposed by NOST, but additional constraints imposed within the OGIP.
First Used/Defined by: NOST standard
Within the OGIP: SECTION INCOMPLETE

EQUINOX
The value field shall contain a floating point number giving the equinox in years for the celestial coordinate system in which positions given in either the header or data are expressed.
Allowed values: No formal constraints imposed by NOST, but additional constraints imposed within the OGIP.
First Used/Defined by: NOST standard
Within the OGIP: The value of the this keyword is restricted to be:

• '1950.0' (with RADECSYS = 'FK4'), or
• '2000.0' (with RADECSYS = 'FK5')

See Also: RADECSYS (Section 8.1)

EPOCH
The value field shall contain a floating point number giving the equinox in years for the celestial coordinate system in which positions given in either the header or data are expressed. The use of this keyword is deprecated in the NOST standard.
Allowed values: No constraints
First Used/Defined by: NOST standard - but now deprecated in favour of EQUINOX (Section 2.2.1)
Within the OGIP: This keyword should not be used, and is effectively replaced by EQUINOX (Section 2.2.1)
See Also: EQUINOX (Section 2.2.1), RADECSYS (Section 8.1)

Bibliographic Keywords

AUTHOR
The value field shall contain a character string identifying who compiled the information in the data associated with the header. This keyword is appropriate when the data originate in a published paper or are compiled from many sources.
Allowed values: No constraints
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints
See Also: CREATOR (Section 7)

REFERENC
The value field shall contain a character string citing a reference where data associated with the header are published. Allowed values: No constraints
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints

Commentary Keywords

COMMENT
This keyword shall have no associated value; columns 9-80 may contain any ASCII text. Any number of COMMENT cards may appear in a header. Similarly, if columns 1-8 contains ASCII blanks, then columns 9-80 may contain any ASCII text, and any number of card images with blank keyword fields may appear in a header.
Allowed values: No constraints
First Used/Defined by: NOST standard
Within the OGIP: Copious COMMENT cards are encouraged; No additional constraints

HISTORY
This keyword shall have no associated value; columns 9-80 may contain any ASCII text. The text should contain a history of steps and procedures associated with the processing of the data. Any number of HISTORY cards images may appear in a header.
Allowed values: No constraints
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints

Array Keywords

BSCALE
This keyword shall be used, along with BZERO, when the array pixel values in the Primary array are not the true physical values. The value is a floating point number which gives the linear multiplicative scaling factor which must be applied to the stored values as part of the transformation between the stored values and the true physical units. The default for this keyword is 1.0.
Allowed values: No constraints
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints See Also: BZERO (Section 2.2.4)

BZERO
This keyword shall be used, along with BSCALE, when the array pixel values in the Primary array are not the true physical values. The value is a floating point number which is the addative offset which must be applied to the stored values as part of the transformation between the stored values and the true physical units (thus the value represents the true physical value of an array value of zero). The default for this keyword is 0.0.
Allowed values: No constraints
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints
See Also: BSCALE (Section 2.2.4)

BUNIT
The value field shall contain a character string describing the physical units in which the quantities in the Primary array are expressed (after the application of BSCALE & BZERO).
Allowed values: The NOST standard recommends the use of the units defined un the IAU Style Guide.
First Used/Defined by: NOST standard
Within the OGIP: The values must conform to the strings and rules given in OGIP/93-001

BLANK
This keyword shall be used in Primary headers with positive values of BITPIX (ie arrays of integer data). The value field shall contain an integer that specifies the representation of array values whose physical values are undefined.
Allowed values: No constraints
First Used/Defined by: NOST standard
Within the OGIP: No additional constraints

CTYPEnnn
The value field shall contain a character string giving the name of the coordinate represented by axis nnn of the Primary array. Where this coordinate represents a physical quantity, units defined in the IAU Style Guide are recommended.
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

CRPIXnnn
The value field shall contain a floating point number identifying the location of a reference point along axis nnn (in the Primary array) in units of the axis index. This value is based ipon a counter that runs from 1 to NAXISnnn with an increment of 1 per pixel. The reference point value need not be that for the center of a pixel nor lie within the actual data array. Use comments to indicate the location of the index point relative to the pixel.
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

CRVALnnn
The value field shall contain a floating point number giving the value of the coordinate specified by the CTYPEnnn keyword at the reference point CRPIXnnn in a Primary array.
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

CDELTnnn
The value field shall contain a floating point number giving the partial derivative of the coordinate specified by the CTYPEnnn keywords with respect to the Primary array pixel index, evaluated at the reference point CRPIXnnn, in units of the coordinate specified by the CTYPEnnn keyword.
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

CROTAnnn
The keyword is used to indicate a rotation from a standard coordinate system described by CTYPEnnn to a different coordinate system in which the values in the Primary array are actually expressed. Rules for such rotations are not further specified by the NOST standard, but it is recommended that the rotation be explained in comments. The value field shall contain a floating point number, giving the rotation angle in degrees between axis nnn and the direction implied by the coordinate system defined by CTYPEnnn.
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

DATAMAX
The value field shall always contain a floating point number (regardless of the value of BITPIX) giving the maximum valid physical value represented in the Primary array (exclusive of any special values).
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

DATAMIN
The value field shall always contain a floating point number (regardless of the value of BITPIX) giving the minimum valid physical value represented in the Primary array (exclusive of any special values).
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

Extension Keywords

EXTNAME
The value field shall contain a character string, to be used to distinguish among different extensions of the same type (ie with the same value of XTENSION) with a file.
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

EXTVER
The value field shall contain an integer, to be used to distinguish among different extensions in a file with the same type and name (ie with the same values of XTENSION & EXTNAME). The values need not start with 1 for the first extension with a particular value of EXTNAME, and need not be in sequence for subsequent values. If EXTVER is absent then the value should be considered to 1.
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

EXTLEVEL
The value field shall contain an integer specifying the level in a heirarchy of extension levels of the extension header containing it. The value shall be 1 for the highest level; levels with a higher value of this keyword shall be subordinate to levels with a lower value. If the EXTLEVEL keyword is absent, the file should be treated as if the value were 1.
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

RESERVED KEYWORDS LIKELY TO ENTER THE NOST STANDARD

The World Coordinate Sytem proposal of Griesen & Calabretta

(Version: 1993 Aug 24 draft)

Griesen & Calabretta have proposed an enhancement to the keywords used to specify the physical coordinate values of pixels in the Primary array such as to address a number of complexities associated with 'real' image projections. In essence their proposal involves the addition of a new keyword, CD$nnnmmm$, to be used in conjunction with the standard keywords (CRVALnnn, CRPIXnnn, CDELTnnn & CTYPEnnn; see Section 2.2.4). The proposal deprecates the use of the CROTAnnn keyword.

CD$nnnmmm$
These keywords are floating point numbers giving the pixel coordinate translation matrix, where nnn & $mmm$ are the axis numbers (each with leading zeros as neccessary to make three digits). The appropriate keyword need not be specified if the corresponding matrix element is zero.
Within the OGIP: A moderately serious objection to this scheme has recently been made on FITSBITS due to a lack of backwards compatibility caused by the deprecation of the use of the CROTAnnn keyword. Thus at the current time, OGIP FITS files should continue using the existing standard.
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: CRVALnnn, CRPIXnnn, CDELTnnn, CTYPEnnn & CROTAnnn (Section 2.2.4)

EXTENSION/FORMAT IDENTIFICATION

At the OGIP we have been developing general formats for high-energy astrophysics data which can accomodate data from different satellite observatories. However, it is not sufficient to merely USE one of the defined formats. We need a way to TELL the reader (either human or software) that we are in fact using a defined format, and to identify the format being used. The purpose of this proposal is to describe our plans for providing this information.

PROPOSAL:

We propose to use the following set of keywords to identify file formats:

HDUCLASS
A character string identifying that defined the FITS format of the extensions and the related HDUCLAS$n$ keyword values. The value of this keyword should be 'OGIP ' for formats defined by the OGIP.
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

HDUDOC
A character string specifying the document (preferably published) that describes the format/classification used.
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

HDUVERS
A character string of the form 1.0.0 indicating the version of the document given by HDUDOC.
clarify this is true...
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

HDUCLAS$n$
A hierarchical set of character string keywords which classify the file format in use. .... etc etc
Allowed values: Section Incomplete
First Used/Defined by: NOST standard
Within the OGIP: Section Incomplete
See Also: Section Incomplete

MISSION/INSTRUMENT RELATED

General

DETNAM
Character string further specifying the precise details concerning the detector in use in cases where INSTRUME is insufficient.
Allowed values: see OGIP/93-013
First Used/Defined by: OGIP/93-013
Within the OGIP: Values must conform to those given in OGIP/93-013
See Also: TELESCOP & INSTRUME (Section 2.2.1)

FILTER
Character string denoting the filter in use.
Allowed values: see OGIP/93-013
First Used/Defined by: OGIP/93-013
Within the OGIP: Values must conform to those given in OGIP/93-013
See Also: TELESCOP & INSTRUME (Section 2.2.1)

OBSERVATION/TARGET RELATED

Observation

OBS_MODE
Character string denoting the observing mode of the satellite/instrument.
Allowed values: see OGIP/94-001
First Used/Defined by: OGIP/94-001
Within the OGIP: Values must conform to those given in OGIP/94-001

DATAMODE
Character string describing the instrumental mode used during the collection of the data.
Allowed values: The value of this keyword is considered instrument-specific, but is often related to the program(s) being executed by the on-board computer.
First Used/Defined by: OGIP/94-001
Within the OGIP: Values must conform to those given in OGIP/94-001

SETUPID
Used to indicate the instrument setup condition prior to the observation.
Allowed values: Instrument-specific
First Used/Defined by: RDF ???
Within the OGIP: Incomplete

Target Details

OBS_ID
Used to store the mission-specific observation identification code.
Allowed values: Incomplete
First Used/Defined by: RDF ???
Within the OGIP: Incomplete

SEQ_PI
Used to list the Principle Investigator of the sequence or observation.
Allowed values: Incomplete
First Used/Defined by: RDF ???
Within the OGIP: Incomplete
See Also: OBJECT (Section 2.2.1)

Related Instrument-Specific Keywords

DATA PROCESSING, PIPELINE etc

CREATOR
The value field shall contain a character string identifying the software program (and version) created the FITS file. (The reserved AUTHOR keyword has sometimes been used for this purpose, but this is not consistent with the original intent of the AUTHOR keyword to cite a publication.) It is intented that this keyword should refer to the program that originally defined the FITS file structure and wrote the contents. If a FITS file is subsequently copied largely intact into a new FITS by another program, then the value of the CREATOR keyword should still refer to the original program. HISTORY keywords should be used instead to document any further processing that is performed on the file after it is created.
Allowed values: No constraints
First Used/Defined by: OFWG Recommendation R7
Within the OGIP: The syntax should be CREATOR = 'progname v1.2.3 where where progname in the name of the s/w task, and 1.2.3 its version number.
See Also: AUTHOR (Section 2.2.2)

Related Instrument-Specific Keywords

SPECIFICATION OF PHYSICAL COORDINATES

Celestial

RADECSYS
A string denoting the stellar reference frame used for the celestial coordinate system in which positions given in either the header or data are expressed.
Allowed values: No formal constraints, but additional constraints imposed within the OGIP.
First Used/Defined by: OGIP/93-003
Within the OGIP: The value of the this keyword is restricted to be:

• 'FK4' (for EQUINOX ='1950.0')
• 'FK5' (for EQUINOX ='2000.0')

See Also: EQUINOX (Section 2.2.1)

Harder stuff

SPECIFICATION OF TIME

General exposure times etc

TELAPSE
This is the time interval, in seconds, obtained as difference between the start and the stop of an observation. Gaps due to Earth occultation, or high background counts and/or other anomalies,if any occurs within an observation, are included.
Allowed values: Positive real, in units of seconds
First Used/Defined by: RDF ???
Within the OGIP: Incomplete

ONTIME
This is the total good time, in seconds, on 'source'. If a GTI table is provided, ONTIME should be calculated as the sum of those intervals.
Allowed values: Positive real, in units of seconds
First Used/Defined by: RDF ???
Within the OGIP: The dead time correction is not included.

LIVETIME
This is the total time, in seconds, on source corrected for the 'total' dead time. The ratio LIVETIME/ONTIME gives the dead time value (ranging therefore between 0-1).
Allowed values: Positive real, in units of seconds
First Used/Defined by: RDF ???
Within the OGIP: Incomplete

EXPOSURE
This is the total time, in seconds, on source corrected for any relevant quantity which are needed to calculate the corrected count/s.The value can include correction which are not directly related with time (e.g. collimation efficiency or vignetting). This keyword should be used in the header of FITS file when is appropriate to give a mean value for all the interesting correction.
Allowed values: Positive real, in units of seconds
First Used/Defined by: RDF ???
Within the OGIP: Incomplete

DEADC
This is the multiplicative dead time correction factor for the instrument. Thus the multiplication of this value for the integration time (TIMEDEL in the case of light curve) or for the ONTIME value gives the 'effective' integration time or LIVETIME. The value rages between 0-1. Since the dead time can be caused by a multitude of reasons (connected either to the particular experiment, or/and if the data were processed by an on board computer, and/or how a particular satellite operates), a good practice should be include all the specific corrections in a single keyword. If more that one effect contributes to the 'total' dead time, specific mission keywords can be used to record the original value for each correction.
If the dead time is related to the sampling of the on board computer, it has been found that different correction are needed for counts (count/s) and errors. This can be generalized to all cases in which the error needs to be treated differently compared to the counts.
Allowed values: Real, in the range 0.0 - 1.0
First Used/Defined by: RDF ???
Within the OGIP: Incomplete

Absolute Times

TIMESYS
Records the time frame system used in the file. Standard values are 'MJD', 'JD' or 'TJD' to define the various Julian day representations. If the time system is defined from an arbitrary UT time, the value is given in decimal years.
Allowed values: As above
First Used/Defined by: OGIP/93-003
Within the OGIP: Mandatory keyword for RATES files (see OGIP/93-003)

TIMEUNIT
The time unit used for the TSTART, TSTOP and TIMEZERO keywords. The TIMEUNIT keyword is provided to enable downstream s/w to make the value of the keywords compatible either with internal conventions, or with the units of the TIME column.
Allowed values: As above
First Used/Defined by: OGIP/93-003
Within the OGIP: Mandatory keyword for RATES files (see OGIP/93-003). The values must conform to the strings and rules given in OGIP/93-001

TSTART The start time of the dataset in the TIMESYS frame with units specified by TIMEUNIT. Should additional precision be required, this keyword can be replaced by:
TSTRATI - giving the integer part of the start time (in units of TIMEUNIT), and
TSTRATF - giving the fractional part of the start time (in units of TIMEUNIT).
Allowed values: As above
First Used/Defined by: OGIP/93-003
Within the OGIP: Mandatory keyword for RATES files (see OGIP/93-003).
See Also: CLOCKCOR

TSTOP
The stop time of the dataset in the TIMESYS frame with units specified by TIMEUNIT. Note that subtraction of the TSTOP and TSTART values gives the duration of the observation represented by the dataset. Should additional precision be required, this keyword can be replaced by:
TSTOPI - giving the integer part of the stop time (in units of TIMEUNIT), and
TSTOPF - giving the fractional part of the stop time (in units of TIMEUNIT).
Allowed values: As above
First Used/Defined by: OGIP/93-003
Within the OGIP: Mandatory keyword for RATES files (see OGIP/93-003).
See Also: CLOCKCOR

TIMEZERO
The value of this keyword is used to calculate the time for each bin or event in the table. To reconstruct the full time specification of the $n^{\rm th}$ event or bin, a residual or a delta time is added to a 'start' value. This 'start' value is stored in the TIMEZERO keyword in the time frame defined by TIMESYS and in units of TIMEUNITS.
Allowed values: As above
First Used/Defined by: OGIP/93-003
Within the OGIP: No additional constraints
See Also: CLOCKCOR

MJDREF
This is the reference time adopted for each mission. Usually different missions have different reference times, defined using a conventient unit system (e.g. i.e. EXOSAT uses the reference time 1980 Jan 01 00:00:00 UT, ROSAT uses MJD = 48043.879745364201881). The refernce time is the only time information which is not affected by any mission-specific correction (e.g. spacecraft clock drift), and therefore can be given in a 'known' system. The proposed 'known' system in which the refernce time for each mission should be written is Modified Julian Day (MJD) defined as MJD = JD - 240000.5. This reference time is given as a safety net to ensure that a time is given in the header that is in a standard form, independent of the time system adopted for the mission.
Allowed values: As above
First Used/Defined by: OGIP/93-003
Within the OGIP: No additional constraints

TIMEREF
In order to facilitate the comparison of data from different missions/observatories, it is necessary to specify a common reference frame for the times given in a datafile. This means that the time tagged in the 'local frame' needs to be recalculated in the common reference frame. This changing of frame is usually known as the 'batrycentric correction' because the time. Allowed values: As above
First Used/Defined by: OGIP/93-003
Within the OGIP: The value of the this keyword is restricted to be:

• 'LOCAL'
• 'SOLARSYSTEM'
• 'HELIOCENTRIC'
• 'GEOCENTRIC'

Corrections to Times

IMAGES

General

Calibration-Related

SPECTRA

General

OTHER

USEFUL LINKS TO OTHER HTML PAGES

The following useful links are available (in the HTML version of this document only):

• Other OFWG FITS Format Documentation

Index

AUTHOR

Bibliographic Keywords

BITPIX

Mandatory Keywords

BLANK

Array Keywords

BLOCKED

Other keywords reserved in

BSCALE

Array Keywords

BUNIT

Array Keywords

BZERO

Array Keywords

CD$nnnmmm$

The World Coordinate Sytem

CDELTnnn

Array Keywords

COMMENT

Commentary Keywords

CREATOR

DATA PROCESSING, PIPELINE etc

CROTAnnn

Array Keywords

CRPIXnnn

Array Keywords

CRVALnnn

Array Keywords

CTYPEnnn

Array Keywords

DATAMAX

Array Keywords

DATAMIN

Array Keywords

DATAMODE

Observation

DATE

Other keywords reserved in

DATE-OBS

Keywords describing observations

DEADC

General exposure times etc

DETNAM

General

END

Mandatory Keywords

EPOCH

Keywords describing observations

EQUINOX

Keywords describing observations

EXPOSURE

General exposure times etc

EXTEND

Mandatory Keywords

EXTLEVEL

Extension Keywords

EXTNAME

Extension Keywords

EXTVER

Extension Keywords

FILTER

General

GCOUNT

Mandatory Keywords

HDUCLAS$n$

EXTENSION/FORMAT IDENTIFICATION

HDUCLASS

EXTENSION/FORMAT IDENTIFICATION

HDUDOC

EXTENSION/FORMAT IDENTIFICATION

HDUVERS

EXTENSION/FORMAT IDENTIFICATION

HISTORY

Commentary Keywords

INSTRUME

Keywords describing observations

LIVETIME

General exposure times etc

MJDREF

Absolute Times

NAXIS

Mandatory Keywords

NAXISnnn

Mandatory Keywords

OBJECT

Keywords describing observations

OBS_ID

Target Details

OBS_MODE

Observation

OBSERVER

Keywords describing observations

ONTIME

General exposure times etc

ORIGIN

Other keywords reserved in

PCOUNT

Mandatory Keywords

RADECSYS

Celestial

REFERENC

Bibliographic Keywords

SEQ_PI

Target Details

SETUPID

Observation

SIMPLE

Mandatory Keywords

TELAPSE

General exposure times etc

TELESCOP

Keywords describing observations

TIMEREF

Absolute Times

TIMESYS

Absolute Times

TIMEUNIT

Absolute Times

TIMEZERO

Absolute Times

TSTART

Absolute Times

TSTOP

Absolute Times

Updates

How to Supply Updates

XTENSION

Mandatory Keywords

About this document ...

This document was generated using the LaTeX2HTML translator Version 99.2beta8 (1.46)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -t OGIP/93-012 -image_type gif -split 3 ogip_93_012.tex

The translation was initiated by Michael Arida on 2001-06-28

HEASARC home page

This file was last modified on Wednesday, 20-Oct-2021 10:40:41 EDT

This page maintained by: Michael Arida (SP Sys); arida@milkyway.gsfc.nasa.gov
HEASARC Guest Observer Facility