Документ взят из кэша поисковой машины. Адрес оригинального документа : http://hea-www.harvard.edu/~jcm/asc/docs/asc/ascfits1.ps Дата изменения: Thu Oct 25 23:20:19 2001 Дата индексирования: Tue Oct 2 10:50:55 2012 Кодировка: Поисковые слова: orion

ASC FITS File Designers' Guide
ASC-FITS-2.0.1 
Arnold Rots and Jonathan McDowell
1999-06-02
Contents
1 Introduction 2
1.1 General style considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 ASC conventions 5
2.1 Time information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 GTI Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 TIME, TSTART and TSTOP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 DATE keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.4 Other time keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Coordinate information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Observation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Other RA and Dec keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Column coordinate systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 What kind of data am I? - the HDUCLAS keywords . . . . . . . . . . . . . . . . . . 15
 $Id: ascts.tex,v 2.0 1999/02/19 21:48:15 arots Exp arots $
1

ASC FITS File Designers Guide 2
2.4 Keywords describing the instrumental setup . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Traceability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 Exposure Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 Count and Count Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 Source and Background related keywords . . . . . . . . . . . . . . . . . . . . . . . . 21
3 AXAF data product header components 23
3.1 \CHANDRA" versus \AXAF" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Mandatory component for Image Primary Header (M) . . . . . . . . . . . . . . . . . 25
3.3 Mandatory component for Null Primary Header (M) . . . . . . . . . . . . . . . . . . 25
3.4 Mandatory component for Binary Table extension (M) . . . . . . . . . . . . . . . . . 27
3.5 Mandatory component for Image extension (M) . . . . . . . . . . . . . . . . . . . . . 27
3.6 Full conguration control component (CC) . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 Short conguration control component (Short CC) . . . . . . . . . . . . . . . . . . . 29
3.8 Conguration control component for null primary HDU (Null CC) . . . . . . . . . . 29
3.9 Level 0 full timing component (T) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.10 Level 0.5-1.5 full timing component (T) . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.11 Level 2 or greater full timing component (T) . . . . . . . . . . . . . . . . . . . . . . 32
3.12 Short timing component (short T) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.13 Full observation info component (O) . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.14 Source info component (S) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.15 Short observation info component (short O) . . . . . . . . . . . . . . . . . . . . . . . 34
3.16 Non-SI observation info component (non-SI O) . . . . . . . . . . . . . . . . . . . . . 34

ASC FITS File Designers Guide 3
A Appendix 1: EXTNAME/HDUCLAS/CONTENT dictionary 35
B Appendix 2: Allowed units from OGIP/93-001 36
C Appendix 3: Processing History Records 38

ASC FITS File Designers Guide 4
1 Introduction
This document contains recommendations for the contents of ASC data product FITS headers. It
is assumed that the reader is familiar with the basics of FITS use.
For general FITS issues, see the information provided by the FITS Support Oфce at GSFC 1 and
the FITS archive at NRAO 2 .
The conventions outlined in this document comply with the FITS standards, of course, but also with
the HEASARC FITS Working Group's 3 recommendations. There is no good document describing
their recommended conventions; the best available are a summary 4 and a more detailed list 5 . We
shall refer to those collectively as HFWG/95.
Additional conventions developed by the ASC are contained in the draft documents on the FITS
REGION table format and the FITS Embedded Function.
1.1 General style considerations
 FITS les allow the possibility of arbitrarily large numbers of extensions (sections, `HDUs')
containing unrelated data. However, we recommend including only one main `object' of
information in each le, with extra extensions only when those extensions contain auxiliary
information relevant specically to the main object. For instance, a le might contain an
event list, together with its associated good time intervals, which apply specically to that
event list.
 Most of our data are best stored in tabular form, and so most data products will contain a
null FITS primary image, followed by a main binary table (BINTABLE) extension containing
the main data (we will call this the Principal HDU), and possibly some auxiliary extensions
(which we will call Auxiliary HDUs). The ASCII table extension type is to be avoided.
 Some of our data are in the form of binned images (of 1, 2 or 3 dimensions). These should
be stored in the primary (rst) HDU of a FITS le which then becomes its principal HDU.
Do not make a null primary image followed by an IMAGE extension, since many FITS image
viewers can only see the data if it is in the primary HDU.
 Each HDU must be as far as possible self contained. Some software extracts a single HDU
without checking the rest of the le, and so we must repeat some of the basic information in
each HDU. We dene below the ASC header styles of a major header and a minor header:
the minor header contains only the most basic information, while the major header contains
all the relevant information about the observation. The principal HDU and (if dierent) the
primary HDU should both have major headers; the remaining HDUs may have minor headers.
1 http://ts.gsfc.nasa.gov/ts home.html
2 http://www.cv.nrao.edu/ts/
3 http://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/ofwg intro.html
4 http://legacy.gsfc.nasa.gov/docs/heasarc/ofwg/ofwg recomm.html
5 ftp://legacy.gsfc.nasa.gov/ts info/ofwg recomm/recomm.txt

ASC FITS File Designers Guide 5
 All HDUs are to contain the DATASUM and CHECKSUM keywords, so that they are properly
checksummed, in conformance with the FITS Checksum Convention proposed by Seaman and
Pence. HDUs following this convention have a 32-bit one's complement checksum that is 0
(all ones). This is an important tool in our quest to ensure the integrity of the archive and
to achieve fault-free le transfers.
 Avoid the use of the '-' (hyphen, minus) character in keyword and column (TTYPEn) names.
Use the underscore (' ') instead. Exception: the hyphen may be used specically to indi-
cate negation. Exception: The preexisting DATE-OBS, DATE-END, MJD-OBS, MJD-END
keywords are retained. (HEASARC rule HFWG/95 R1).
 Every column in a TABLE or BINTABLE extension shall be given a unique name using the
TTYPEn keyword. This name shall include only upper or lower case letters, digits, and the
underscore character; it shall not include embedded blanks (trailing blanks are not signicant)
and it shall begin with a letter (ASC may wish to use leading digits in some cases, violating
this rule). Case shall not be considered signicant in searching for names, (so COL NAME
and col Name are not considered to be unique) but names shall be returned by software as
they are, so low level software must write and read them in a case sensitive way. Names shall
be unique within the rst 16 characters. (HEASARC rule HFWG/95 R15).
 Names need to be unique within each FITS header. Since several systems allow for particular
data to be stored either in keywords or in columns, keyword and columns names are required
to be unique. This means that within the same header one cannot have a keyword and a
column with the same name.
 TLMINn and TLMAXn are used to record the minimum and maximum legal (i.e., meaning-
ful) values for a column. For instance, they are used to dene the image size for a positional
column in an event list. (HFWG/95 R6) These keywords should be used for all table columns
for which they are meaningful, since they are a key piece of information used by the XSELECT
program.
 Units given in FITS les, for example those given as values of TUNITn or CUNITn, should
follow the convention of OGIP/93-001, (HFWG/95 R5) basically SI with some astronomical
additions. Case is important in units { the classic example is the use of 'S', which is a unit of
electrical conductance, and dierent from 's' which is a unit of time. Some units are allowed
to have SI prexes ('k' for kilo, etc.) and others are not. See the table of allowed units in
Appendix 2.
Compound units are formed using spaces to imply multiplication and / to imply division of
the immediately following token, with tokens grouped by round parentheses (). The operator
** implies raising to the power. For example, 'erg /(cm**2 s)' is erg per sq cm per s, while
'erg /cm**2 s' is erg s per sq cm. Numerical prexes of the form 10**n may be given, e.g.
'10**(-12) erg /(cm**2 s)'.
A restricted list of functional operators is also (reluctantly) permitted in unit strings. These
are:
{ log, ln, exp, sqrt
{ sin, cos, tan, asin, acos, atan, sinh, cosh, tanh

ASC FITS File Designers Guide 6
although I would strongly discourage the use of the second group (sin, etc.). It is better to
make the quantity dimensionless before you take its sin.
 String valued keywords in standard FITS are limited to 68 characters. To store a longer string
in a header keyword, we use multiple keywords as follows: the string is split into segments of
no more than 67 characters; each segment is terminated with the ampersand character & and
written as an ordinary string keyword. The rst keyword shall be the actual keyword name,
subsequent keywords shall all be named CONTINUE and will be FITS no-value keywords,
recognized by the absence of the equals sign. In addition, les using this convention will
include the keyword LONGSTRN = 'OGIP 1.0'. (HFWG/95 R13). Example:
LONGSTRN= 'OGIP 1.0'
AUTHOR = 'J.C. McDowell, &' / Author keyword
CONTINUE 'G. d''Aurillac, V.I. Ulyan&' / Continuation
CONTINUE 'ov, and L.D. Ahenobarbus' /
REFERENC= 'Journal of Improbable CoAuthors, &' /
CONTINUE 'Vol 1., No. 1, p. 42.'/
 Quality ags (integer values used to encode the fact that data may have particular kinds
of problem) should use the value zero to mean `good data' and non-zero values to indicate
varying degrees of bad or masked out data. (HFWG/95 R9).
 All FITS les should contain, in HISTORY keywords, the names of the data product les
that were used as input for creating the current le. A draft design for complete processing
history information encoding is presented in Appendix 3.

ASC FITS File Designers Guide 7
2 ASC conventions
2.1 Time information
The observation start and stop times are the most important pieces of data, and are carried in
redundant ways. The TSTART and TSTOP keywords are the primary carriers of this information;
the DATE-OBS and DATE-END keywords and the MJD-OBS keywords repeat the information in
a format which is easier for the human reader. For specifying good time intervals one should use
the HEASARC-style GTI tables (binary tables containing two columns: START and STOP).
2.1.1 GTI Tables
For integration with the Data Model, we require the addition of the following keywords in the
header of GTI tables:
MTYPE1 = 'TIME'
MFORM1 = 'START,STOP'
METYP1 = 'R'
When we have implemented vector columns and range elements, this will tell the Data Model that
the start and stop columns on the GTI are a range on the quantity time.
2.1.2 TIME, TSTART and TSTOP
All time tags in the table data, and all TSTART and TSTOP values, should be mission time
measured in seconds from an AXAF specied mission reference epoch.
 The AXAF reference epoch for calibration data was 1993 Dec 31, 00:00:00 UTC.
 The AXAF reference epoch for ight data shall be 1998 Jan 1, 00:00:00 TT, or MJD 50814.0 TT.
 The reference epoch used shall be stored as an MJD (modied Julian Date) value in the header
keyword MJDREF or, alternatively, MJDREFI and MJDREFF (integer and fractional parts)
if greater precision is needed.
 The time tags shall be the total number of seconds in a continuous count since the reference
epoch.
 To convert a time tag TIME to an absolute MJD(TT), use the formula

ASC FITS File Designers Guide 8
MJD(TT) = MJDREF(TT) + ( TIMEZERO + TIME ) / 86400
where the TIMEZERO header keyword contains a time adjustment in seconds (usually zero).
 When converting to UTC calendar dates, remember that you may need to account for leap
seconds. As long as you stick with the time tags, or TT calendar dates, leap seconds are not
a problem.
 Clock correction (or time conversion) parameters are stored in the ve keywords BTIMNULL
(s), BTIMRATE (s/count), BTIMDRFT (s/(count*count)), BTIMCORR (s), STARTOBT
(s). Here, the relation between VCDU count n v
and Mission Elapsed Time (MET) is:
MET = T 0;b
+R b  n v
+ 0:5  D b  n 2
v
+ T c;b
where:
BTIMNULL = T 0;b
BTIMRATE = R b
BTIMDRFT = D b
BTIMCORR = T c;b
The VCDU count is a 24-bit number constructed by adding the minor frame count to the
major frame count times 128 (or: left-shifted by 7 bits). STARTOBT is the On-Board
Time transmitted in the telemetry closest to STARTMJF and STARTMNF; it only serves to
discriminate between dierent rool-overs and resets of the VCDU count.
In Level 0 data, we expect the recorded times (excluding TIMEZERO) to be calculated
using the rst three terms, with T c;b
recorded in TIMEZERO (and, hence, TIMEZERO =
BTIMCORR). For higher products, the rst three coeфcients serve as a ducial clock (basic
time, see below), with BTIMCORR indicating the dierence between basic time and the times
recorded using the best available estimate of the clock corrections. In the higher products,
the TIMEZERO keyword will be set to zero. The CLOCKAPP keyword will always be set
to true (T).
2.1.3 DATE keywords
There is a family of DATE keywords, of which we use DATE (date of FITS le creation), DATE-
OBS (date of observation start), and DATE-END (date of observation end). The format of these
keywords is currently undergoing a change in the FITS standard to handle the year 2000 problem.
Dates prior to 1999 Jan 1 are required to be written the old way, but for the purposes of AXAF
we will deem 1999 to start early so we don't have to have IF statements everywhere. The old style
required two keywords, e.g. , DATE-OBS and TIME-OBS:
DATE-OBS= '23/02/98' / Day, month, year as per FITS standard
TIME-OBS= '11:22:33' / Hour minute second UTC as per FITS standard

ASC FITS File Designers Guide 9
The new format uses the ISO standard date representation ccyy-mm-ddThh:mm:ss, and combines
the date and time info into one keyword:
DATE-OBS= '1999-02-23T11:22:33' / ISO standard date and time
2.1.4 Other time keywords
 MJDREF records the Modied Julian Day of the mission time zero point. It implies a
coordinate system on the TIME column, with the TCRVLn value of MJDREF, an implied
TCRPXn of 0.0 and TCUNIn of 'd'. (See the section below on column coordinate systems
for the meanings of TCRVL, TCRPX and TCUNI). For greater precision, it can be split into
integer and fractional parts MJDREFI and MJDREFF.
 TSTART and TSTOP record the start time and stop time of the observation, in units of
TIMEUNIT since MJDREF (unless TIMESYS='MJD' or 'JD'). They can be split into integer
and fractional parts TSTARTI, TSTARTF, TSTOPI, TSTOPF. If a TIME column is present
in the data, its TUNITn value must be the same as TIMEUNIT.
 TIMEDEL records the time resolution of the data: the bin size between rows for a binned
dataset, the resolution of the time stamp for event lists.
 TIMEPIXR indicates where in each bin the time stamp falls. It has a value between 0.0 and
1.0. The default is 0.5 (center of the bin). If the time stamp refers to the beginning of the bin
(as is the case for event data if the event was received between TIME and TIME+TIMEDEL),
one should set TIMEPIXR=0.0.
 TIMEZERO and TIMEDEL record the time of the bins in a binned dataset. The nominal
time of the time bin center of row n is TIMEZERO +(n 0:5 TIMEPIXR ) TIMEDEL.
The keywords have the unit of TIMEUNIT. TIMEZERO can be split into TIMEZERI and
TIMEZERF.
 For record-based (binned) data, TSTART shall represent the start of the rst record, TSTOP
the end of the last record, i.e. :
TSTART = (Time of rst record) TIMEPIXR  TIMEDEL
TSTOP = (Time of last record) + (1 TIMEPIXR)  TIMEDEL
 For event-based data, TSTART and TSTOP shall dene the time range during which data
were taken, in the same way this is dened for good time intervals in GTI tables. Hence,
such tables shall not contain time tags that are earlier than TSTART or later than TSTOP.
 TIMESYS records the time system used for MJDREF. We will use TIMESYS = 'TT '. When
the time is corrected to the barycenter of the solar system TIMESYS = 'TDB' (but see also
TIMEREF and PLEPHEM below).
This system supports three dierent time systems at once: the absolute MJD time system (given
in MJDREF); the system used to record header times (given in TIMESYS); and the system used

ASC FITS File Designers Guide 10
to record times in the table itself (given in TIMESYS and the TUNITn keyword). For example,
suppose we have:
MJDREF = 44238.0 / Reference time
TIMESYS = 'TT ' / Time system
TIMEUNIT= 'd ' / Time unit
TIMEZERO= 14.0 / Time zero point
TTYPE1 = 'TIME ' / Time column
TUNIT1 = 'd ' / Time unit
TSTART = 0.1 /
TSTOP = 0.2 /
TIME
0.01
0.02
Then the rst row encodes a time which is 0.01d from TIMEZERO, which is 14.0 days from
MJDREF=44238.0, in other words 1980 Jan 14.01. If instead we have
MJDREF = 44238.0 / Reference time
TIMESYS = 'MJD ' / Time system
TIMEUNIT= 'd ' / Time unit
TIMEZERO= 44252.0 / Time zero point
TTYPE1 = 'TIME ' / Time column
TUNIT1 = 'd ' / Time unit
TSTART = 0.01 /
TSTOP = 0.02 /
TIME
0.01
0.02
This is unneccessarily baroque for most purposes, and the following is essentially equivalent and
much more generic (requiring fewer new keyword inventions):
TSTART = 0.0 /
TSTOP = 8640.0 /
TTYPE1 = 'TIME ' / Time column
TUNIT1 = 's ' / Time unit
TCTYP1 = 'DATE ' / Absolute date
TCUNI1 = 'd ' / Date unit
TCRVL1 = 44252.0 / Reference value
TCRPX1 = 0.0 / Reference pixel

ASC FITS File Designers Guide 11
TIME
1800.0
3600.0
We recommend the following style and convention. TIMEUNIT ='s', always. A very simple
transformation from VCDU number to basic time will be dened for the duration of the mission.
This conversion will be documented in the keywords BTIMNULL, BTIMRATE, and BTIMDRFT.
All clock corrections (given in BTIMCORR) will be relative to basic time. In les at Level 0 and
below, all times (TIME column, TSTART, TSTOP) will be in basic time and both TIMEZERO
BTIMCORR will contain the best clock correction available at the time the le was created. Files
above Level 0 will have TIMEZERO = 0.0, with all clock corrections applied, so that TSTART,
TSTOP etc. and the values in the TIME column are true time, but write the clock correction
(relative to basic time) in BTIMECORR. This convention allows later clock corrections to be
applied without the need for reprocessing. Include a WCS on the TIME column so that generic
software can convert the times to absolute dates, assuming that CLOCKAPP = T. Simple software
can then ignore TIMESYS, TIMEUNIT, TIMEZERO and just use MJDREF or TCRVL1, while
the other keywords are retained for HEASARC compatibility and all information about clock
corrections is retained. This gives us:
MJDREF = 50814.0 / Reference time
TIMESYS = 'TT ' / Time system
TIMEUNIT= 's ' / Time unit
TIMEZERO= 0.0 / 0.896745 is the cumulative clock correction
TSTART = 1209600.0 / Seconds since MJDREF
TSTOP = 1218240.0 / Seconds since MJDREF
CLOCKAPP= T /
COMMENT Column related keywords
TTYPE1 = 'TIME ' / Time column
TUNIT1 = 's ' / Time unit
TCTYP1 = 'DATE ' / Absolute date
TCUNI1 = 'd ' / Date unit
TCRVL1 = 50814.0 / Reference value
TCRPX1 = 0.0 / Reference pixel
TCDLT1 = 1.15740740741e-05 /
TIME
1211400.0
1213200.0
 TIMEREF records what corrections have been made to event times. It applies only to tables
which contain a single time which represents a photon arrival time. The default value is
TIMEREF='LOCAL' which means that the actual arrival time is stored. Other values give
a location and indicate that TIME has been corrected to the time that other photons in the
same wavefront would have arrived at the given location. Note that this is NOT a change of
time frame, since it depends on the direction the photon is coming from. For a wide eld of

ASC FITS File Designers Guide 12
view instrument, two photons with the same arrival time but coming from dierent directions
would have dierent corrected times. Note that this makes the denition of TSTART and
TSTOP, etc., problematic unless a specic direction (RA OBJ or RA PNT, for instance) is
intended.
The possible locations (values of TIMEREF) are: 'GEOCENTRIC' (Earth center), 'HELIO-
CENTRIC' (Sun center), and 'SOLARSYSTEM' (Solar system barycenter). This last value
is implied when TIMESYS = 'TDB'. See also PLEPHEM, below.
When photon times with dierent location corrections are stored in dierent columns of
the same le, HEASARC recommends that the column name itself be given special val-
ues, DIFFERENT from the corresponding values of TIMEREF. GEOCENTRIC maps to
REFEARTH, HELIOCENTRIC maps to REFSUN, and SOLARSYSTEM maps to REFB-
SOLS. In addition, special keywords for each of these cases replace TSTART, TSTOP and
TIMEZERO, namely ESTART, ESTOP, ETIMEZER, SSTART, SSTOP, STIMEZER, and
BSTART, BSTOP, BTIMEZER. Note that these special keywords for each case would not
have been needed if some kind of WCS-type indexed keyword had been used to store time
coordinate information. This is not one of HEASARC's most well-considered recommenda-
tions and such practices are not to be encouraged. Note also, that TIMESYS may become
ambiguous.
 Another keyword which has a slightly dierent meaning to TIMEREF is TASSIGN. TASSIGN
\species where the time assignment of the data is done. for example, for EXOSAT time
assignment was made at the Madrid tracking station, so TASSIGN ='Madrid'. Since the
document goes on to state that this information is relevant for barycentric corrections, one
assumes that this means what is of interest is not the location of the computer where time
tags where inserted into the telemetry stream, but whether those time tags refer to the actual
photon arrival time or to the time at which the telemetry reached the ground station, etc.
For example, for Einstein the time assignment was performed at the ground station but
corrected to allow for the transmission time between satellite and ground, so I presume in
this case TASSIGN='SATELLITE'. I believe that for AXAF, TASSIGN = 'SATELLITE'.
OGIP/93-003 also species the location for the case of a ground station should be recorded
the keywords GEOLAT, GEOLONG, and ALTITUDE. This is rather unfortunate since it
would be nice to reserve these keywords for the satellite ephemeris position. However, since
no ground station is dened for AXAF, we feel that we can use GEOLONG, GEOLAT, and
ALTITUDE for these purposes, especially since such usage is consistent with their usage for
ground-based observations. TASSIGN has obviously no meaning when TIMESYS = 'TDB'.
 TIERRELA and TIERABSO give the dimensionless clock rate error and the absolute timing
precision in seconds. They may be included for informational purposes.
 PLEPHEM indicates, when times are corrected to the barycenter of the solar system, which
planetary ephemeris was used. There are two legal values, at present: 'JPL-DE405' and
'JPL-DE200'. The former will be the normal value. However, one should be aware that it
can only be used in conjunction with RADECSYS = 'ICRS', whereas the latter value can
only be used with RADECSYS = 'FK5'. In certain cases it may be necessary to use DE200,
e.g., when one needs to compare the data with a timing ephemeris that is derived on the
basis of DE200. To summarize, the following keyword value combinations are legal:

ASC FITS File Designers Guide 13
TIMESYS = 'TDB ' / Time scale: Barycentric Dynamical Time
TIMEREF = 'SOLARSYSTEM' / Reference location of photon arrival times
EQUINOX = 2000.0 / J2000
RADECSYS= 'ICRS ' / International Celestial Reference System
PLEPHEM = 'JPL-DE405' / Planetary ephemeris used
and:
TIMESYS = 'TDB ' / Time scale: Barycentric Dynamical Time
TIMEREF = 'SOLARSYSTEM' / Reference location of photon arrival times
EQUINOX = 2000.0 / J2000
RADECSYS= 'FK5 ' / International Celestial Reference System
PLEPHEM = 'JPL-DE200' / Planetary ephemeris used
2.2 Coordinate information
As a rule, coordinates are to be specied using the corrdinate systems given in the documents SDS-
2.0, Coordinate Systems, SDS-9.0 FITS names for ASC Coordinates, and SDS-12.0 Coordinate
system design for data model, all by Jonathan McDowell. For calibration-related coordinate issues,
see also the applicable HEASARC documents.
For regularly spaced coordinates, it appears that consensus is building in the FITS community
to have the pixel grid dened by an NAXIS  NAXIS matrix stored in the keywords \CDi j".
However, since the formal acceptance of the current WCS proposal is still some way o and since
it is not clear what the status of the CDELTi and CROTAi keywords is going to be, we shall allow
both forms to be used in the ASC: either CDi j or CDELTi and CROTAi. In addition, alternate
coordinate axis may be indicated by adding WCS keywords that have a letter appended, such as
CTYPE1A, CDELT1A, CUNIT1A, etc.
We have adopted one additional convention for specifying enumerated coordinates (irregularly
spaced bins or pixels. If, for instance, the third coordinate of a multi-dimensional image in the
primary array is energy ('ENERG'), sampled irregularly, the actual energy values of the pixels may
be listed in a subsequent extension in the same le, with the referencing done as follows.
HDU0:
...
NAXIS3 = 10 / Number of pixels along 3rd axis
CTYPE3 = 'ENERG_BIN' / Name of this pseudo coordinate
CD3_3 = 1 / Pixel increment (or CDELT3)
CRPIX3 = 1 / Better make this 1
CRVAL3 = 1 / ... And this one, too, or confusion will reign
CEXTN3 = 'ENERGY_BINS' / It will be enumerated in an HDU with EXTNAME='ENERGY_BINS'
CEXTV3 = 1 / ... and EXTVER=1 (first HDU of that name if CEXTV omitted)

ASC FITS File Designers Guide 14
...
HDU1:
...
TFIELDS = 2 / Needs to be at least 2
NAXIS2 = 10 / There are 10 rows (at least NAXIS3 above)
...
EXTNAME = 'ENERGY_BINS' / EXTNAME
EXTVER = 1
TTYPE1 = 'ENERG_BIN' / First column: the bin numbers
TFORM1 = '1I'
TTYPE2 = 'ENERG' / Second column: the real energy values
TFORM2 = '1D'
TUNIT2 = 'keV'
...
This introduces the new keywords CEXTNi and CEXTVi, which link a table in the same FITS le
to a particular coordinate axis. CEXTVi is optional.
The HDU with the enumerated coordinate pixels needs to:
 ... have the same EXTNAME as CEXTNi.
 ... have a column with TTYPE identical to the value of CTYPEi.
 ... have a column with TTYPE the name of the \real" coordinate axis.
If the table provides pixel (bin) bounds, rather tha pixel coordinate values, the example above
would look like this (HDU1 only):
...
TFIELDS = 3 / Needs to be at least 2
NAXIS2 = 10 / There are 10 rows (at least NAXIS3 above)
...
EXTNAME = 'ENERGY_BINS' / EXTNAME
EXTVER = 1
TTYPE1 = 'ENERG_BIN' / First column: the bin numbers
TFORM1 = '1I'
TTYPE2 = 'ENERG_LO' / Second column: the lower energy bin bounds
TFORM2 = '1D'
TUNIT2 = 'keV'
TTYPE3 = 'ENERG_HI' / Third column: the upper energy bin bounds
TFORM3 = '1D'
TUNIT3 = 'keV'
...

ASC FITS File Designers Guide 15
Of course, that table may have more rows than NAXISi; and CRPIXi, CDELTi, and CRVALi need
not be 1; but one should not complicate matters when it's not necessary.
2.2.1 Observation Details
Observation details derived from the observation catalog will be included in Level 1 products and
beyond.
 OBJECT is the name of the target.
 OBSERVER is the principal investigator of the observation.
 OBS ID is a string denoting the observation.
 SEQ NUM is the observation's sequence number designated by USG.
 TITLE is the proposal title.
 RA NOM and DEC NOM, in degrees, are the nominal ICRS/J2000 RA and Dec of the
observation, used as the center of the sky plane. At Level 1 processing these may be overridden
with values actually derived from the aspect solution, if those con ict with the planned ones.
 EQUINOX = 2000.0 denotes that all equatorial coordinate positions use equinox 2000.0.
(HFWG/95 R3)
 RADECSYS = 'ICRS' denotes that our positions derive from the ICRS (Hipparcos) reference
frame, rather than the earlier FK4 or FK5 systems. (Actually our star catalog is technically
an ICRS/FK5 hybrid, but is consistent with ICRS within our errors). (HFWG/95 R3)
 ROLL NOM, in degrees, is the nominal roll angle of the observation. At Level 1 processing
this may be overridden with a value actually derived from the aspect solution, if this con ict
with the planned one.
2.2.2 Other RA and Dec keywords
The following keywords may also be used, but we won't normally have them.
 RA OBJ and DEC OBJ record the position of the source, if the data le contains data on
a single extracted source (or if there is a dened target source). Values are decimal degrees.
(HFWG/95 R3)
 RA PNT, DEC PNT, and ROLL PNT record the mean pointing direction of the telescope
optical axis during the observation. (HFWG/95 R3)
 RA SCX, DEC SCX, RA SCY, DEC SCY, RA SCZ, DEC SCZ record the orientation of the
spacecraft X, Y and Z axes in the equatorial coordinate frame. (HFWG/95 R3)

ASC FITS File Designers Guide 16
2.2.3 Column coordinate systems
The HEASARC conventions for storing coordinate systems in columns will be followed.
We can distinguish three types of coordinate system transformations in FITS les: linear transfor-
mations on a single axis or column, two-dimensional projections on a pair of axes or columns, and
linear matrix transformations on all the axes and columns. I believe that the last type is needed
only in rare cases.
For single-axis rescalings, we use the following algorithm: the data quantity p with name P is
related to a world coordinate x with name X by
x = x 0
+
(p p 0
)
P can be an IMAGE axis or a TABLE/BINTABLE column.
Table 1: Simple coordinate keywords
Quantity Meaning IMAGE keyword TABLE keyword
P data quantity name - TTYPEn
X coordinate name CTYPEn TCTYPn
and transform type
p 0
Reference pixel CRPIXn TCRPXn
x 0 Reference value CRVALn TCRVLn

Pixel increment CDELTn TCDLTn
For two-dimensional coordinates, the standard FITS WCS does not explicitly tie the two columns
together. You use a special pair of CTYPE/TCTYP value strings, e.g.
TTYPE4 = 'X'
TTYPE5 = 'Y'
TCTYP4 = 'RA---TAN'
TCTYP5 = 'DEC--TAN'
which combine both the coordinate names and the transform projection type. For the ASC data
model, we introduce extra keywords to group columns together under a common name:
MTYPE1 = 'POS'
MFORM1 = 'X,Y'
MTYPE2 = 'EQPOS'
MFORM2 = 'RA,DEC'
Finally, the keyword TDBINi may be used to specify a binning size for a binary table column, to
let data model software know how to bin by default; the units are TUNITi:

ASC FITS File Designers Guide 17
TDBIN1 = 4.2 / Default bin size
2.3 What kind of data am I? - the HDUCLAS keywords
Each HDU should contain information allowing generic software to identify what kind of data it
contains.
 The FITS standard keyword EXTNAME is used to give the name of an HDU. The ASC
keyword HDUNAME plays a similar role but may be dierent if EXTNAME has to have
some other value for compatibility reasons. In a primary HDU, there is some argument that
EXTNAME is illegal, and so there we always use HDUNAME. EXTNAME is more generic
and is augmented by EXTVER which numbers extensions with the same EXTNAME in a
single le. The conventions are:
{ The DM will always write both EXTNAME and HDUNAME except in the case of the
primary extension, HDU0, when only HDUNAME is written.
{ HDUNAME will contain the DM block name.
{ The value of EXTNAME and EXTVER will be determined as follows: any trailing digits
on the block name will be peeled o and used as the value of EXTVER. The remaining
characters of the blockname will be used as EXTNAME.
{ On reading, the DM will set the block name to be HDUNAME if it is present, otherwise
it will use EXTNAME, concatenated with EXTVER if EXTVER is present.
{ EXTVER will be a non-negative integer with a default value of 1.
 The ASC keyword CONTENT is used to store basic information about the content of a le
and is the primary key when searching for a particular data product in the arcive. Hence,
each data product has been assigned a unique value for the CONTENT keyword, except for
science data where ACIS and HRC may produce functionally but not structurally identical
products.
 The HDUCLAS hierarchy is used by FTOOLS and other software to determine the type of a
le. HDUCLAS gives the origin of the hierarchy, either 'OGIP' or 'ASC'. HDUCLAS1 gives
the highest level letype, e.g. 'LIGHTCURVE', HDUCLAS2 is more specic, e.g. 'NET',
HDUCLAS3 more specic still, e.g. 'RATE'. All HDUs have an HDUCLAS1 keyword, but
the presence of the subsequent enumerated HDUCLAS keywords depends on the type of
HDU.
 The ASC keyword HDUSPEC contains, if applicable, a (human readable) reference to the
Interface Control Document (ICD) or other design document, including its version, that
species the detailed format of the HDU.
The dictionary of EXTNAME, content and HDUCLAS keywords is given at the end of this docu-
ment; hence, this document is referenced in HDUDOC.

ASC FITS File Designers Guide 18
2.4 Keywords describing the instrumental setup
 MISSION is used to dene the overall project, e.g. AXAF, HTXS, etc., even when dierent
telescopes (e.g. ground based cal optics) are being used. This keyword is an ASC internal
invention and is not yet adopted by HEASARC. The ASC keyword MISSION = 'AXAF'
labels data as being part of the AXAF project, even if not taken with the AXAF (Chandra)
telescope; it is used to group together ground cal data with ight data.
 TELESCOP is a FITS standard reserved keyword; HEASARC (OGIP/93-013 R12) species
the strings used in particular missions. We will use the following values:
Table 2: TELESCOP keyword values
Value Use
CHANDRA Flight
(AXAF) Flight
XRCF/HRMA XRCF

ASC FITS File Designers Guide 19
 INSTRUME is a FITS standard reserved keyword. HEASARC (OGIP/93-013 R12) speci-
es that INSTRUME should refer to the focal plane instrument even when a grating is in
place, i.e., INSTRUME='HRC', not INSTRUME='LETGS'. We consider ACIS to be a single
instrument, since any six of its chips can be read out.
We use the following values:
Table 3: INSTRUME keyword values
Value Use Description
ACIS Flight, XRCF AXAF CCD Imaging Spectrometer subsystem
HRC Flight, XRCF High Resolution Camera subsystem
EPHIN Flight
PCAD Flight Pointing Control and Attitude Determination subsystem
TEL Flight Telescope subsystem
SIM Flight Science Instrument Module subsystem
OBC Flight Software subsystem
CCDM Flight Communications Command and Data Management subsystem
CPE Flight CPE hardware and software subsystem
EPS Flight Electrical Power Subystem
THM Flight Thermal control subsystem
SMS Flight Structure subsystem
PROP Flight Propulsion and pyro subsystems
MISC Flight Other AXAF signals
ORBIT Flight Orbit ephemeris
SOLAR Flight Solar ephemeris
LUNAR Flight Lunar ephemeris
CLOCK Flight Clock measurements
AXAF Flight Certain mission-level items
FPC XRCF
SSD XRCF
HSI XRCF
HRC-I XRCF
HRC-S XRCF
ACIS-2C XRCF
PCAD includes ACA, Gyro, Earth and Sun Sensors, Attitude, Earth Angle. SPACECRAFT
includes Power, Thermal, Status, Alignment, Grating, SIM, HRMA, Telemetry. GENERAL
includes Orbit Ephemeris, Orbit Events, Mission Timeline.
 GRATING is introduced to record the gratings. We will use the values LETG and HETG
(and TOGA at XRCF), and (optionally) NONE.

ASC FITS File Designers Guide 20
 DETNAM is used in HEASARC OGIP/93-013 R12 to record the sub-detector or combination
of sub-detectors used. We recommend for the AXAF science instrument the following: in
general, use ACIS- followed by the chip numbers in use (any 6 for ACIS, e.g. ACIS-012789).
However, we prefer certain mnemonics for the commonly used cases:
Table 4: DETNAM keyword values
DETNAM Equivalent INSTRUME
HRC-I HRC
HRC-S HRC
HRC-SI HRC
ACIS-I ACIS-012367 ACIS
ACIS-S ACIS-456789 ACIS
ACA-P PCAD
ACA-R PCAD
GYRO PCAD
FSSA PCAD
CSSA PCAD
ESA PCAD
GRATING TEL
HRMA TEL
In fact we hope always to use the mnemonics. Note that DETNAM is not required.
 FILTER is not used in this mission. By default, the FILTER keyword will be omitted which
is equivalent to the value \NONE".
 OBS MODE (OGIP/94-001) is used to record the observing mode. The valid values are
'POINTING', 'SLEW', 'RASTER', and 'SCAN', of which POINTING and SLEW are used
by AXAF. ASC also uses the value 'GROUND' to denote ground calibration data and 'SEC-
ONDARY' for data from the secondary (\next in line"; i.e. the one not primarily selected for
the observation) science instrument.
 DATAMODE (OGIP/94-001) is used for detector operating modes. Values for the ASCA SIS
CCD were BRIGHT, FAINT, FAST. In the ASCA project, the DATAMODE keyword was
changed when extra information was added to the data in later processing, thus it re ected
not the way the data was taken but the current state of processing. We believe that it
is better to retain information on the original experiment conguration, and determine the
current state of processing from the presence or absence of the appropriate table columns.
We note this is an incompatibility with ASCA.
For AXAF HRC, we will use: OBSERVING, NEXT IN LINE (note these refer to the teleme-
try mode in use, not the actual purpose of the observation). For AXAF ACIS, we earlier
used: GRADED, RAW, HISTO, FAINT, FAINT-BIAS, SPECIAL. These values have now
been revised. The new values are:

ASC FITS File Designers Guide 21
Table 5: DATAMODE keyword values for ACIS
ACIS mode DATAMODE
TE Raw RAW
TE Histogram HISTO
TE Faint FAINT
TE Faint with Bias FAINT BIAS
TE Very Faint VFAINT
TE Graded GRADED
TE Graded Histogram GRADED HISTO
CC Raw CC RAW
CC Faint CC FAINT
CC Graded CC GRADED
CC 3x3 Faint CC33 FAINT
CC 3x3 Graded CC33 GRADED
Other SPECIAL
 READMODE is an ASC ACIS-specic keyword used to denote the ACIS read mode. It has
values TIMED or CONTINUOUS to denote whether the data is in timed exposure (TE) or
continuous clocking (CC) mode.
An example of a standard observation identication segment of the FITS header would then be:
MISSION = 'AXAF ' / Project
TELESCOP= 'CHANDRA ' / Telescope
INSTRUME= 'HRC ' / Instrument
GRATING = 'LETG ' / Grating
DETNAM = 'HRC-S ' / Detector
OBS_MODE= 'POINTING' / Observation mode
DATAMODE= 'OBSERVING' / Data mode
2.5 Traceability
In order to facilitate tracing the pedigree of the FITS les, the following keywords need to be
included:
 ORIGIN contains place where the le is created; always 'ASC'.
 CREATOR contains the name of the program/tool that created the le, plus version infor-
mation. Example: 'mytool - Version 12.7.3'.
 ASCDSVER provides the ASC-DS release that CREATOR was part of, such as 'R4C2.0'.

ASC FITS File Designers Guide 22
 TLMVER is only required for Level 0 products and contains the IP&CL version, for instance
'IP&CL 6.6'.
 REVISION is an integer that indicates the version of the data. this is intended to be incre-
mented for each reprocessing run.
2.6 Exposure Keywords
 ONTIME records the sum of all good time intervals. TELAPSE records the dierence between
the start and stop times of an observation. LIVETIME records the ONTIME corrected for
dead time corrections. EXPOSURE is the time corrected for all eects, including spatial ones
such as vignetting, that are specied. Beware that Xspec wants a value for EXPOSURE;
hence, it is prudent to include an EXPOSURE keyword in spectral and light curve headers,
even if the contents is identical to LIVETIME. This should not lead to confusion since the
corrections applied to EXPOSURE are all explicitly named in the various \correction applied"
logical keywords. All of these should have units of seconds. (HFWG/95 R11). TELAPSE is
not particularly profound and its use is optional.
 DEADC is equal to LIVETIME/ONTIME and is used to record the dead time correction, in
the range 0 to 1. (O HFWG/95 R11). It may be used as a table column if the correction
varies from row to row. (OGIP/93-003). If several energy bands are present with dierent
corrections, the DEADC column is a vector with one value per band; as a header keyword it
is replaced by the indexed keyword DEADCn. SAO has historically used DTCOR instead of
DEADC. For reasons of PROS compatibility we shall use DTCOR.
 DEADAPP = T indicates that dead time corrections have been applied to count rates in the
le. (OGIP/93-003).
2.7 Count and Count Rate
Count and count rate data are described in OGIP/92-007 and OGIP/93-003. There are two
paradigms for storing count and count rate data. In type I tables, the table can store one de-
tector channel or energy band per table row, with one corresponding count or count rate value
each. In type II tables, each table row contains the entire set of count values for all channels or
bands, the corresponding channel or band values are inferred from header keywords, and the dif-
ferent rows represent the changing of some other parameter such as time. In this case, the keyword
NUMBANDS gives the number of dierent count values per row.
 NUMBANDS gives the number of dierent bands for type II les. (OGIP/93-003)
 COUNTS, of type integer, is a table column giving the uncorrected counts. In type II les,
it is an array of NUMBANDS values. (OGIP/92-007, OGIP/93-003)

ASC FITS File Designers Guide 23
 RATE, of type real, is a table column giving the count rate. In type II les, it is an array
of NUMBANDS values. RATE and COUNTS should not both be present. (OGIP/92-007,
OGIP/93-003)
 ERROR, of type real, is a table column giving the error on the COUNTS or the RATE.
(OGIP/93-003)
 BACKV, of type real, is a table column giving the background value. (OGIP/93-003). Al-
though OGIP/93-003 does not say this explicitly, we assume that if the table contains the
COUNTS column, BACKV is interpreted as being the background counts, while if the table
contains RATE, BACKV is interpreted as being the background rate. It is recommended to
include a TUNITn keyword to this eect, in order to avoid unnecessary confusion. If BACKV
is constant with row number, it is used as a header keyword; if NUMBANDS is more than 1,
an indexed keyword BACKVn is used.
 BACKE, of type real, is a table column giving the error on BACKV. (OGIP/93-003). The
keyword BACKEn allows storage of these values as an indexed header keyword, similar to
BACKVn.
2.8 Source and Background related keywords
These keywords presume the existence of a `source' and a `background', usually dened as spatial
subsets of a set of observational data. The keywords are mostly meaningful for histogram tables
such as PHA les and light curves. The specication of spatial ltering that is applied to the data
may be presented in the format of a REGION table (see ASC-FITS-REGION-1.0).
 ERRCOR is used to apply a correction to the errors. The denition is unclear, but I am
guessing what is meant is that in a PHA dataset or light curve dataset with counts and
errors on counts, software which applies a conversion to counts/s and errors on count/s using
correction factors such as VIGNET should multiply the error by this extra value. (HFWG/95
R11)
 GEOAREA records the geometric area of the detector, usually in sq. cm. (OGIP/93-003).
 AREASCAL is an `area scaling factor' which is used to renormalize the histogram. It is an
alternative to the use of an ARF calibration le; usually we use the ARF and set AREASCAL
equal to 1.
 VIGNET is used to record the vignetting factor needed to convert the data to the equivalent
on-axis values. The keyword is used for datasets which contain uncorrected values, not
to record a correction which has already been made. The denition is value(on-axis) =
value(datale) / VIGNET. It usually lies between zero and one.
 VIGNAPP = T indicates that vignetting corrections have been applied. It is dened in
OGIP/93-003 where it refers specically to the values of RATE.
 BACKFILE is the lename of a background data le associated with the current one.

ASC FITS File Designers Guide 24
 BACKSCAL is a `background scaling factor' which will be applied to the data in BACKFILE
when it is used with the given dataset.
 BACKAPP = T indicates that background subtraction has been performed. As currently
dened it applies specically to the values of the RATE column (OGIP/93-003).
 NPIXSOU and NPIXBACK are used to record the area in pixels of the source and background
regions. (OGIP/93-003).
 CORRFILE is a `correction le', containing a spectrum that is to be subtracted from the
source spectrum.
 CORRSCAL is used to scale the data in the correction le.
 RESPFILE is the spectral response matrix RMF le to be used with the data.
 ANCRFILE is the ancillary response le (eective area versus energy) to be used with the
data.
 POISSERR is a logical keyword set to T if Poission rather than Gaussian errors should be
used with the data. In a table with a column COUNTS, the STAT ERR statistical errors
may be omitted and inferred from the COUNTS if POISSERR is T.
 SYS ERR is the fractional systematic error on the data in a column called COUNTS or
RATE.
 QUALITY is a quality ag describing the data. As a header keyword, it usually is used with
value zero to indicate that all the data is good.
 BPIXFILE is the name of the le containing the bad pixel map.

ASC FITS File Designers Guide 25
3 AXAF data product header components
We dene the following header components:
 M: Mandatory FITS keywords for HDU type
 CC: Conguration control component
 T: Timing component
 O: Observation info component
 IC: Image coordinate system keywords (CTYPEn, etc.)
 TC: Table column specications (TTYPE, etc. ) and coordinate system (TCRPIX) and
ranges (TLMIN/TLMAX)
Each of the rst three has full and short versions which are dened below. The components should
be present as follows:
Table 6: Required FITS header components
Type FITS Primary ASC Principal Header components
or extension or auxiliary
Image Primary Principal M, CC, T, O, IC
Null Primary Aux M, Null CC, Short T, Short O
Table Extn Principal M, CC, T, O, TC
Table Extn Aux M, Short CC, Short T, Short O, TC
Image Extn Aux M, Short CC, Short T, Short O, IC
The components should appear in the order specied, followed by optional additional COMMENT and
HISTORY keywords, and the END keyword as the very last one. Non-Science Instrument data les
should use the non-SI O component in all HDUs. If there is any uncertainty as to the precise
intention, please consult the text of this document.
Entries marked with hash marks (#) are required to be populated by software. In the reference
components, brackets ([ ]) surround keywords that must only be included per the notes. The notes
provide additional instructions or limitations. A leading blank ( ) must be deleted from each header
line prior to use. Each header line is 80 characters long. The HDU number n in the comment eld
of the SIMPLE and XTENSION keywords (for example, zero in the following:
/ HDU 0==========================================) must be updated to represent the ac-
tual ordinal value of the HDU in the FITS le, counting from zero. All components are terminated
wither by a blank line or by a blank line followed by the END keyword.

ASC FITS File Designers Guide 26
3.1 \CHANDRA" versus \AXAF"
As of ASC-FITS-2.0.0 we allow various AXAF/Chandra synonyms. This potentially aects six
keywords, the old versions of which are:
HDUDOC = 'ASC-FITS-1.4: McDowell, Rots: ASC FITS File Designers Guide'
ASCDSVER= '########' / ASC-DS processing system revision (release)
ORIGIN = 'ASC '
TIMVERSN= 'ASC-FITS-1.4' / AXAF FITS design document
MISSION = 'AXAF ' / Mission is AXAF
TELESCOP= 'AXAF ' / Telescope is AXAF
The new versions:
HDUDOC = 'ASC-FITS-2.0: Rots, McDowell: ASC FITS File Designers Guide'
ASCDSVER= '########' / ASC-DS processing system revision (release)
ORIGIN = 'ASC '
TIMVERSN= 'ASC-FITS-2.0' / AXAF FITS design document
MISSION = 'AXAF ' / Mission is AXAF
TELESCOP= 'CHANDRA ' / Telescope is CHANDRA
It seemed prudent to leave the rst four alone, except to allow reading software to recognize
secondary synonyms:
HDUDOC:
HDUDOC = 'ASC-FITS-2.0: McDowell, Rots: ASC FITS File Designers Guide'
HDUDOC, synonym for reading:
HDUDOC = 'CXC-FITS-2.0: McDowell, Rots: CXC FITS File Designers Guide'
ASCDSVER, only allowed:
ASCDSVER= '########' / ASC-DS processing system revision (release)
ORIGIN:
ORIGIN = 'ASC '
ORIGIN, synonym for reading:
ORIGIN = 'CXC '
TIMEVERSN:
TIMVERSN= 'ASC-FITS-2.0' / AXAF FITS design document
TIMEVERSN, synonym for reading:
TIMVERSN= 'CXC-FITS-2.0' / AXAF FITS design document

ASC FITS File Designers Guide 27
In order to maintain compatibility with XRCF data, we keep AXAF as the primary choice for
MISSION, but change TELESCOP (although, upon reading, synonyms will be recognized):
MISSION:
MISSION = 'AXAF '
MISSION, synonym for reading:
MISSION = 'CHANDRA '
MISSION = 'CXO '
TELESCOP:
TELESCOP= 'CHANDRA '
TELESCOP, synonym for reading:
TELESCOP= 'AXAF '
TELESCOP= 'CXO '
3.2 Mandatory component for Image Primary Header (M)
The following keywords are required to appear in the given order at the top of the header, with
the END keyword being the last keyword of the header.
SIMPLE = T / HDU 0==========================================
BITPIX = # / Number of bits per data pixel
NAXIS = # / Number of data axes
[NAXIS1 = # / Number of pixels on first axis ]
[NAXIS2 = # / Number of pixels on second axis ]
EXTEND = T / FITS dataset may include extensions
END
Notes: (1) There must be as many NAXISi keywords as the value of NAXIS.
3.3 Mandatory component for Null Primary Header (M)
The following keywords are required to appear in the given order at the top of the header, with
the END keyword being the last keyword of the header.
SIMPLE = T / HDU 0==========================================
BITPIX = 8 / Number of bits per data pixel
NAXIS = 0 / Number of data axes

ASC FITS File Designers Guide 28
EXTEND = T / FITS dataset may include extensions
END

ASC FITS File Designers Guide 29
3.4 Mandatory component for Binary Table extension (M)
The following keywords are required to appear in the given order at the top of the header, with
the END keyword being the last keyword of the header.
XTENSION= 'BINTABLE' / HDU 1==========================================
BITPIX = 8 / 8-bit bytes
NAXIS = 2 / 2-dimensional Binary Table
NAXIS1 = # / Number of bytes per row
NAXIS2 = # / Number of rows
PCOUNT = 0 / No group parameters (required keyword)
GCOUNT = 1 / One data group (required keyword)
TFIELDS = # / Number of columns
EXTNAME = '########' / EXTNAME, usually identical to HDUNAME
[EXTVER = # / EXTVER - sequence number of HDU ]
END
Notes: (1) EXTVER is mandatory only if more than one HDU exists with the same EXTNAME
in one le.
3.5 Mandatory component for Image extension (M)
The following keywords are required to appear in the given order at the top of the header, with
the END keyword being the last keyword of the header.
XTENSION= 'IMAGE ' / HDU 1==========================================
BITPIX = # / 8-bit bytes
NAXIS = # / Number of image axes
NAXIS1 = # / Number of pixels along axis 1
[NAXIS2 = # / Number of pixels along axis 2 ]
PCOUNT = 0 / No group parameters (required keyword)
GCOUNT = 1 / One data group (required keyword)
EXTNAME = '########' / EXTNAME, usually identical to HDUNAME
[EXTVER = # / EXTVER - sequence number of HDU ]
END
Notes:
(1) There must be as many NAXISi keywords as the value of NAXIS.
(2) EXTVER is mandatory only if more than one HDU exists with the same EXTNAME.

ASC FITS File Designers Guide 30
3.6 Full conguration control component (CC)
COMMENT +------------------+
COMMENT | AXAF FITS File |
COMMENT +------------------+
COMMENT *********************************************************
COMMENT > This file is written following certain AXAF-ASC <
COMMENT > conventions which are documented in ASC-FITS-2.0 <
COMMENT *********************************************************
/ Configuration control block--------------------
ORIGIN = 'ASC '
CREATOR = '### - Version ###'
ASCDSVER= '########' / ASC-DS processing system revision (release)
[TLMVER = '########' / Telemetry revision number (IP&CL) ]
REVISION= # / Processing version of data
CHECKSUM= '################' / ASCII encoded HDU checksum
DATASUM = '##########' / Data unit checksum written in ASCII
CONTENT = '########' / Data product identification
HDUNAME = '########' / Dataset name; usually identical to EXTNAME
HDUSPEC = '######## ' / ICD reference
HDUDOC = 'ASC-FITS-2.0: Rots, McDowell: ASC FITS File Designers Guide'
HDUVERS = '########'
HDUCLASS= '########'
HDUCLAS1= '########'
[HDUCLAS2= '########' ]
[HDUCLAS3= '########' ]
LONGSTRN= 'OGIP 1.0' / The OGIP long string convention may be used.
COMMENT This FITS file may contain long string keyword values that are
COMMENT continued over multiple keywords. This convention uses the '&'
COMMENT character at the end of a string which is then continued
COMMENT on subsequent keywords whose name = 'CONTINUE'.
[HISTORY Input event file: hrcx123456789N000_evt0.fits ]
[HISTORY PARM :infile=hrcx123456789N000_evt0.fits ASC00001]
Notes:
(1) The keyword TLMVER is only required for L0 products.
(2) The number of HDUCLASi keywords is variable and depends on the data product. HDUCLASS
and HDUCLAS1 are mandatory. HDUCLAS2 and higher are optional and must be included only
if populated with non-blank values.
(3) The format of the HDUVERS keyword is 'i.j.k ', and should be be populated with a default
value of '1.0.0 '.
(4) The HDUCLASS keyword must be populated with either 'OGIP ' or 'ASC ' as appropriate.
(5) We expect that HISTORY keywords will eventually be written in a standard format; until such
time, both formats above are legal.

ASC FITS File Designers Guide 31
3.7 Short conguration control component (Short CC)
/ Configuration control block--------------------
ORIGIN = 'ASC '
CREATOR = '### - Version ###'
CHECKSUM= '################' / ASCII encoded HDU checksum
DATASUM = '##########' / Data unit checksum written in ASCII
CONTENT = '########' / What data product
HDUNAME = '########' / Dataset name; usually identical to EXTNAME
HDUDOC = 'ASC-FITS-2.0: Rots, McDowell: ASC FITS File Designers Guide'
HDUVERS = '########'
HDUCLASS= '########'
HDUCLAS1= '########'
[HDUCLAS2= '########' ]
[HDUCLAS3= '########' ]
Notes:
(1) The number of HDUCLASi keywords is variable and depends on the data product. HDUCLASS
and HDUCLAS1 are mandatory. HDUCLAS2 and higher are optional and must be included only
if populated with non-blank values.
(2) The format of the HDUVERS keyword is 'i.j.k ', and should be be populated with a default
value of '1.0.0 '.
(3) The HDUCLASS keyword must be populated with either 'OGIP ' or 'ASC ' as appropriate.
3.8 Conguration control component for null primary HDU (Null CC)
/ Configuration control block--------------------
ORIGIN = 'ASC '
CREATOR = '### - Version ###'
CHECKSUM= '################' / ASCII encoded HDU checksum
DATASUM = '##########' / Data unit checksum written in ASCII

ASC FITS File Designers Guide 32
3.9 Level 0 full timing component (T)
/ Time information block-------------------------
DATE = '####-##-##T##:##:##' / Date and time of file creation (UTC)
DATE-OBS= '####-##-##T##:##:##' / TT, with clock correction if CLOCKAPP
DATE-END= '####-##-##T##:##:##' / TT, with clock correction if CLOCKAPP
TIMESYS = 'TT ' / AXAF time will be TT (Terrestrial Time)
MJDREF = 50814 / 1998-01-01T00:00:00 (TT) expressed in MJD (TT)
/ MJD = JD - 2400000.5
TIMEZERO= # / Clock correction (if not zero)
TIMEUNIT= 's '
BTIMNULL= # / Basic Time offset (s)
BTIMRATE= # / Basic Time clock rate (s / VCDUcount)
BTIMDRFT= # / Basic Time clock drift (s / VCDUcount^2)
BTIMCORR= # / Correction applied to Basic Time rate (s)
TIMEREF = 'LOCAL ' / No pathlength corrections
TASSIGN = 'SATELLITE' / Spacecraft clock
CLOCKAPP= T / Clock correction applied
TIERRELA= # / Short-term clock stability
TIERABSO= # / Absolute precision of clock correction
TIMVERSN= 'ASC-FITS-2.0' / AXAF FITS design document
TSTART = # / As in the "TIME" column: raw space craft clock;
TSTOP = # / add TIMEZERO and MJDREF for absolute TT
STARTMJF= # / Major frame count at start
STARTMNF= # / Minor frame count at start
STARTOBT= # / On-Board MET close to STARTMJF and STARTMNF
STOPMJF = # / Major frame count at stop
STOPMNF = # / Minor frame count at stop
TIMEPIXR= # / Time stamp reference as bin fraction
TIMEDEL = # / Time resolution of data (in seconds)
Notes:
(1) If a dierent value for TIERRELA is not determined, a default value of 1.0E-9 should be used.
(2) If a dierent value for TIERABSO is not determined, a default value of 1.0E-4 should be used.

ASC FITS File Designers Guide 33
3.10 Level 0.5-1.5 full timing component (T)
/ Time information block-------------------------
DATE = '####-##-##T##:##:##' / Date and time of file creation (UTC)
DATE-OBS= '####-##-##T##:##:##' / TT, with clock correction if CLOCKAPP
DATE-END= '####-##-##T##:##:##' / TT, with clock correction if CLOCKAPP
TIMESYS = 'TT ' / AXAF time will be TT (Terrestrial Time)
MJDREF = 50814 / 1998-01-01T00:00:00 (TT) expressed in MJD (TT)
/ MJD = JD - 2400000.5
TIMEZERO= # / Clock correction (if not zero)
TIMEUNIT= 's '
BTIMNULL= # / Basic Time offset (s)
BTIMRATE= # / Basic Time clock rate (s / VCDUcount)
BTIMDRFT= # / Basic Time clock drift (s / VCDUcount^2)
BTIMCORR= # / Correction applied to Basic Time rate (s)
TIMEREF = 'LOCAL ' / No pathlength corrections
TASSIGN = 'SATELLITE' / Spacecraft clock
CLOCKAPP= T / Clock correction applied
TIERRELA= # / Short-term clock stability
TIERABSO= # / Absolute precision of clock correction
TIMVERSN= 'ASC-FITS-2.0' / AXAF FITS design document
TSTART = # / As in the "TIME" column: raw space craft clock;
TSTOP = # / add TIMEZERO and MJDREF for absolute TT
TIMEPIXR= # / Time stamp reference as bin fraction
TIMEDEL = # / Time resolution of data (in seconds)
Notes:
(1) If a dierent value for TIERRELA is not determined, a default value of 1.0E-9 should be used.
(2) If a dierent value for TIERABSO is not determined, a default value of 1.0E-4 should be used.

ASC FITS File Designers Guide 34
3.11 Level 2 or greater full timing component (T)
/ Time information block-------------------------
DATE = '####-##-##T##:##:##' / Date and time of file creation (UTC)
DATE-OBS= '####-##-##T##:##:##' / TT, with clock correction if CLOCKAPP
DATE-END= '####-##-##T##:##:##' / TT, with clock correction if CLOCKAPP
TIMESYS = 'TT ' / AXAF time will be TT (Terrestrial Time)
MJDREF = 50814 / 1998-01-01T00:00:00 (TT) expressed in MJD (TT)
/ MJD = JD - 2400000.5
TIMEZERO= # / Clock correction (if not zero)
TIMEUNIT= 's '
TIMEREF = 'LOCAL ' / No pathlength corrections
TASSIGN = 'SATELLITE' / Spacecraft clock
CLOCKAPP= T / Clock correction applied
TIERRELA= # / Short-term clock stability
TIERABSO= # / Absolute precision of clock correction
TIMVERSN= 'ASC-FITS-2.0' / AXAF FITS design document
TSTART = # / As in the "TIME" column: raw space craft clock;
TSTOP = # / add TIMEZERO and MJDREF for absolute TT
TIMEPIXR= # / Time stamp reference as bin fraction
TIMEDEL = # / Time resolution of data (in seconds)
Notes:
(1) If a dierent value for TIERRELA is not determined, a default value of 1.0E-9 should be used.
(2) If a dierent value for TIERABSO is not determined, a default value of 1.0E-4 should be used.
3.12 Short timing component (short T)
/ Time information block-------------------------
DATE = '####-##-##T##:##:##' / Date and time of file creation (UTC)
DATE-OBS= '####-##-##T##:##:##' / TT, with clock correction if CLOCKAPP
DATE-END= '####-##-##T##:##:##' / TT, with clock correction if CLOCKAPP
TIMESYS = 'TT ' / AXAF time will be TT (Terrestrial Time)
CLOCKAPP= T / Clock correction applied (if false)
TIMEZERO= # / Clock correction (if not zero)
TIMEUNIT= 's '
MJDREF = 50814 / 1998-01-01T00:00:00 (TT) expressed in MJD (TT)
TSTART = # / As in the "TIME" column: raw space craft clock;
TSTOP = # / add TIMEZERO and MJDREF for absolute TT

ASC FITS File Designers Guide 35
3.13 Full observation info component (O)
Only include those keywords which are determined by that stage of processing.
/ Observation information block------------------
[OBSERVER= '########' / Name of Principal Investigator/Guest Observer ]
[TITLE = '########' / Proposal title ]
[OBS_ID = '########' / ObsId/Sequence number ]
[SEQ_NUM = '########' / Sequence number ]
MISSION = 'AXAF ' / Mission is AXAF
TELESCOP= 'CHANDRA ' / Telescope is CHANDRA
INSTRUME= '########' / HRC, ACIS, EPHIN, S/C subsystems
DETNAM = '########' / Detector name
GRATING = '########' / Grating
[OBS_MODE= '########' / Pointing, slew, raster, or scan ]
[DATAMODE= '########' / Datamode (varies only for science instr. data) ]
SIM_X = # / Position of SIM in mm
SIM_Y = # /
SIM_Z = # /
FOC_LEN = # / Assumed focal length, mm; Level 1 and up
ONTIME = # / Sum of GTIs
LIVETIME= # / Ontime multiplied by DTCOR
EXPOSURE= # / Total exposure time, with all known corr. appl.
DTCOR = # / Dead time correction
DATACLAS= '########' / Data class
Notes:
(1) The keywords OBSERVER and TITLE should be included only if the associated values are
determined.
(2) OBS ID is the observation Id; its presence depends on processing level (not available before
L1).
(3) SEQ NUM is the sequence number; its presence depends on processing level (not available
before L1).
(4) GRATING must be one of 'NONE ', 'LETG ', or 'HETG '.
(5) The keywords OBS MODE and DATAMODE should be included only if the associated values
are determined.
(6) The default value for DTCOR is 1.0 if not otherwise determined.
(7) The default value for DATACLAS is 'OBSERVED' unless another value (SIMULATED) is
specied.

ASC FITS File Designers Guide 36
3.14 Source info component (S)
Appended to full observation info component (O) only if source information is available.
/ Source information block-----------------------
OBJECT = '########' / Source name
RA_NOM = # / Nominal pointing right ascension, deg
DEC_NOM = # / Nominal pointing declination, deg
ROLL_NOM= # / Nominal roll angle, deg
EQUINOX = 2000.0 / J2000.0
RADECSYS= 'ICRS ' / Julian coordinate reference frame
3.15 Short observation info component (short O)
/ Observation information block------------------
[OBS_ID = '########' / ObsId/Sequence number ]
[SEQ_NUM = '########' / Sequence number ]
MISSION = 'AXAF ' / Mission is AXAF
TELESCOP= 'CHANDRA ' / Telescope is CHANDRA
INSTRUME= '########' / HRC, ACIS, EPHIN, S/C subsystems
Notes: (1) OBS ID is the observation Id; its presence depends on processing level (not available
before L1).
(2) SEQ NUM is the sequence number; its presence depends on processing level (not available
before L1).
3.16 Non-SI observation info component (non-SI O)
/ Observation information block------------------
MISSION = 'AXAF ' / Mission is AXAF
TELESCOP= 'CHANDRA ' / Telescope is CHANDRA
INSTRUME= '########' / HRC, ACIS, EPHIN, S/C subsystems

ASC FITS File Designers Guide 37
A Appendix 1: EXTNAME/HDUCLAS/CONTENT dictionary
Note that this appendix is now largely empty and present for illustrative purposes only. The table it-
self is a living document; the current version can be found at http://hea-www.harvard.edu/arots/asc/ts/content.txt
but is also accessible through links from the Archive pages on the ASC-DS home page and from
the authors home page http://hea-www.harvard.edu/arots.
In addition, that document contains the standard FITS header components from this document in
ASCII form and the le naming convention.
Data product HDUNAME CONTENT HDUCLASS HDUCLAS1 HDUCLAS2 HDUCLAS3
Primary Products
L1 Events EVENTS EVT1 OGIP EVENTS ALL
GTI GTI OGIP GTI ALL
L1(TG) Events EVENTS TGEVT OGIP EVENTS ALL
Mission Timeline MTL MTL OGIP TEMPORALDATA TSI
L2 Events EVENTS EVT2 OGIP EVENTS ACCEPTED
GTI GTI OGIP GTI STANDARD
REGION REGION ASC REGION STANDARD
L2 Spectrum SPECTRUM SPECTRUM OGIP SPECTRUM TOTAL COUNT
GTI GTI OGIP GTI STANDARD
L2 Spectrum SPECTRUM SPEC BKG OGIP SPECTRUM BKG COUNT
GTI GTI OGIP GTI STANDARD
L2 Lightcurve LIGHTCURVE LIGHTCURVE OGIP LIGHTCURVE TOTAL RATE
GTI GTI OGIP GTI STANDARD
L2 Lightcurve LIGHTCURVE LTCRV BKG OGIP LIGHTCURVE BKG RATE
Secondary Products
L2 Summary SUMMARY SUMMARY ASC CONFIG ALL
Sky image IMAGE IMG OGIP IMAGE TOTAL
Aspect solution ASPECT ACASOL OGIP TEMPORALDATA ASPECT
Source list SRCLIST SRC OGIP SRCLIST
Source Regions SRCREG SRCREG ASC REGION
Observed Bkg BKG BKG ASC IMAGE BACKGROUND
Orbit ephemeris EPHEM EPHEM OGIP TEMPORALDATA EPHEM
Aspect offsets ASPOFF ACAOFF ASC TEMPORALDATA ASPOFF
Supporting Products
L0 Events EVENTS EVT0 OGIP EVENTS ALL

ASC FITS File Designers Guide 38
B Appendix 2: Allowed units from OGIP/93-001
Table 8: OGIP/93-001 SI prexes
HEASARC Prex SI prex Value
y yocto (y) 10 24
z zepto (z) 10 21
a atto (a) 10 18
f femto (f) 10 15
p pico (p) 10 12
n nano (n) 10 9
u micro () 10 6
m milli (m) 10 3
c centi (c) 10 2
d deci (d) 10 1 (deprecated)
da deca (D) 10 (deprecated)
h hecto (h) 10 2 (deprecated)
k kilo (k) 10 3
M mega (M) 10 6
G giga (G) 10 9
T tera (T) 10 12
P peta (P) 10 15
E exa (E) 10 18
Z zetta (Z) 10 21
Y yotta (Y) 10 24
Note in particular the use of the ASCII letter u in the HEASARC system to represent the symbol
 in the SI system.
Table 9: OGIP/93-001 allowed units
Unit Name Type Prex?
m metre SI Y
kg kilogram SI Y (on g)
s second SI Y
rad radian SI Y
sr steradian SI Y
K kelvin SI Y
A ampere SI Y
mol mole SI Y
cd candela SI Y
Hz hertz SI Y
J joule SI Y
W watt SI Y
V volt SI Y

ASC FITS File Designers Guide 39
N newton SI Y
Pa pascal SI Y
C coulomb SI Y
ohm ohm SI Y
S siemens SI Y
F farad SI Y
Wb weber SI Y
T tesla SI Y
H henry SI Y
lm lumen SI Y
lx lux SI Y
deg arc degree N
arcsec arc second N
arcmin arc minute N
min minute N
h hour N
yr Julian year 365.25d N
d day N
eV electron volt Y
erg erg N
angstrom angstrom N
AU astronomical unit N
lyr light year N
pc parsec Y
Jy Jansky Y
mag stellar magnitude N
Crab Crab ux Y
G gauss N
count counts N
photon photons N
pixel pixel N
barn barn N
chan detector channel N
adu analog-to-digital converter unit N
bin bin N
voxel 3-D pixel N
byte byte N

ASC FITS File Designers Guide 40
C Appendix 3: Processing History Records
The processing history of ASC data products shall be inserted at the end of the headers of principal
HDUs through HISTORY keywords.
The format shall be:
1 2 3 4 5 6 7 8
12345678901234567890123456789012345678901234567890123456789012345678901234567890
HISTORY llll :ssssssssssssssssssssssssssssssssssssssssssssssssssssssssASCnnnnn
llll label in columns 10-13 : TOOL | PARM | CONT
s..s string in columns 17-72
nnnnn Sequence number in columns 76-80, with leading zeroes
TOOL
The string contains the tool's name and version, separated by one or more blanks.
PARM
The string contains one (or more?) = pairs
CONT
Continuation; the contents in columns 17-72 will be concatenated with the contents of columns
17-72 of the HISTORY keyword that has a sequence number one less than that of the current one.
These HISTORY keyword values will be used in the order specied by the sequence number, not
necessarily in the order in which they appear.
The short version will contain only the parameters \inle" and \outle", the long version all
parameters.
Example:
HISTORY TOOL :mytool 12.03.09 ASC00001
HISTORY PARM :infile=something.img ASC00002
HISTORY PARM :outfile=/local/data/xebec/arots/mydata/axaf/b1509/resultASC00003
HISTORY CONT :s/fileWithALongName ASC00004