Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ îðèãèíàëüíîãî äîêóìåíòà : http://hea-www.harvard.edu/~jcm/asc/docs/ps/SDS05.ps Äàòà èçìåíåíèÿ: Wed Mar 11 23:33:58 1998 Äàòà èíäåêñèðîâàíèÿ: Tue Oct 2 10:48:23 2012 Êîäèðîâêà: Ïîèñêîâûå ñëîâà: http astrokuban.info astrokuban

ASC FITS File Designers' Guide
ASC­FITS­1.0
Jonathan McDowell and Arnold Rots
1998­03­10
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 Office 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.
1.1 General style considerations
ffl FITS files 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 file, with extra extensions only when those extensions contain auxiliary
information relevant specifically to the main object. For instance, a file might contain an
events list, together with its associated good time intervals, which apply specifically to that
events list.
ffl 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
1 http://fits.gsfc.nasa.gov/fits home.html
2 http://www.cv.nrao.edu/fits/
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/fits info/ofwg recomm/recomm.txt
1

ASC FITS File Designers Guide 2
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.
ffl Some of our data are in the form of binned images (of 1, 2 or 3 dimensions). These should
be stored in the primary (first) HDU of a FITS file 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.
ffl Each HDU must be as far as possible self contained. Some software extracts a single HDU
without checking the rest of the file, and so we must repeat some of the basic information in
each HDU. We define 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 different) the
primary HDU should both have major headers; the remaining HDUs may have minor headers.
ffl 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 \Gamma0
(all ones). This is an important tool in our quest to ensure the integrity of the archive and
to achieve fault­free file transfers.
ffl Avoid the use of the '­' (hyphen,minus) character in keyword and column (TTYPEn) names.
Use the underscore (' ') instead. Exception: the hyphen may be used specifically to indi­
cate negation. Exception: The preexisting DATE­OBS, DATE­END, MJD­OBS, MJD­END
keywords are retained. (HEASARC rule HFWG/95 R1).
ffl 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 significant)
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 significant 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 first 16 characters. (HEASARC rule HFWG/95 R15).
ffl 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 define 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.
ffl Units given in FITS files, 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 different from 's' which is a unit of time. Some units are allowed
to have SI prefixes ('k' for kilo, etc.) and others are not. See table of allowed units at end of
document.
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

ASC FITS File Designers Guide 3
** 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 prefixes of the form 10**n may be given, e.g.
'10**(­12) erg /(cm**2 s)'.
A restricted list of functional operators is also permitted in unit strings. These are:
-- log, ln, exp, sqrt
-- sin, cos, tan, asin, acos, atan, sinh, cosh, tanh
although I would strongly discourage the use of the second group (sin, etc.). ­ better to make
the quantity dimensionless before you take its sin.
ffl 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 first 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, files 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.'/
ffl Quality flags (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).

ASC FITS File Designers Guide 4
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 specified mission reference epoch.
ffl The AXAF reference epoch for calibration data was 1993 Dec 31, 00:00:00 UTC.
ffl The AXAF reference epoch for flight data shall be 1998 Jan 1, 00:00:00 TT, or MJD 50814.0 TT.
ffl The reference epoch used shall be stored as an MJD (modified Julian Date) value in the header
keyword MJDREF, or alternatively MJDREFI and MJDREFF (integer and fractional parts)
if greater precision is needed.
ffl The time tags shall be the total number of seconds in a continuous count since the reference
epoch.
ffl To convert a time tag TIME to an absolute MJD(TT), use the formula
MJD(TT) = MJDREF(TT) + ( TIMEZERO + TIME ) / 86400

ASC FITS File Designers Guide 5
where the TIMEZERO header keyword contains a time adjustment in seconds (usually zero).
ffl 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.
ffl In Level 0 data, the time tags may not be corrected for clock drift. In this case, the best
estimate clock correction will be stored in the TIMEZERO keyword. In higher level products,
the clock correction should be applied and (TBR) the clock correction polynomial coefficients
used shall be stored in the keywords CLOCK0, CLOCK1, ... CLOCKn. The TIMEZERO
keyword will be set to zero, but the total correction used will be stored as a comment. The
CLOCKAPP = T (CLOCKAPP = F) keyword is used to record whether or not the clock
correction has been applied to the time tags.
2.1.3 DATE keywords
There is a family of DATE keywords, of which we use DATE (date of FITS file 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
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
ffl MJDREF records the Modified 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.
ffl 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.

ASC FITS File Designers Guide 6
ffl 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.
ffl 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.
ffl 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 \Gamma 1)\Lambda TIMEDEL. The keywords have
the unit of TIMEUNIT. TIMEZERO can be split into TIMEZERI and TIMEZERF.
ffl 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 different 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
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 first 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 /

ASC FITS File Designers Guide 7
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
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 defined for the duration of the mission.
All clock corrections will be relative to basic time. In files at Level 0 and below, all times (TIME
column, TSTART, TSTOP) will be in basic time and TIMEZERO will contain the best clock
correction available at the time the file 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 the comment field of
TIMEZERO. 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

ASC FITS File Designers Guide 8
TCUNI1 = 'd ' / Date unit
TCRVL1 = 50814.0 / Reference value
TCRPX1 = 0.0 / Reference pixel
TCDLT1 = 1.15740740741e­05 /
TIME
1211400.0
1213200.0
ffl 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 field of
view instrument, two photons with the same arrival time but coming from different directions
would have different corrected times. Note that this makes the definition of TSTART and
TSTOP, etc., problematic unless a specific 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 different location corrections are stored in different columns of
the same file, 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.
ffl Another keyword which has a slightly different meaning to TIMEREF is TASSIGN. TASSIGN
``specifies 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 specifies the location for the case of a ground station should be recorded
the keywords GEOLAT, GEOLONG, and ALTITUDE. This is rather unfortunate since it

ASC FITS File Designers Guide 9
would be nice to reserve these keywords for the satellite ephemeris position. However, since
no ground station is defined 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'.
ffl TIERRELA and TIERABSO give the dimensionless clock rate error and the absolute timing
precision in seconds. They may be included for informational purposes.
ffl 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:
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
2.2.1 Observation Details
Observation details derived from the observation catalog will be included in Level 1 products and
beyond.
ffl OBJECT is the name of the target.
ffl OBSERVER is the principal investigator of the observation.
ffl OBS ID is a string denoting the observation.
ffl TITLE is the proposal title.

ASC FITS File Designers Guide 10
ffl 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 conflict with the planned ones.
ffl EQUINOX = 2000.0 denotes that all equatorial coordinate positions use equinox 2000.0.
(HFWG/95 R3)
ffl 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)
ffl 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 conflict
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.
ffl RA OBJ and DEC OBJ record the position of the source, if the data file contains data on
a single extracted source (or if there is a defined target source). Values are decimal degrees.
(HFWG/95 R3)
ffl RA PNT, DEC PNT, and ROLL PNT record the mean pointing direction of the telescope
optical axis during the observation. (HFWG/95 R3)
ffl 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)
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 files: 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 + \Delta(p \Gamma p 0 )
P can be an IMAGE axis or a TABLE/BINTABLE column.

ASC FITS File Designers Guide 11
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
\Delta 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:
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.
ffl The FITS standard keyword EXTNAME is used to give the name of an HDU; it may be
overridden by the ASC keyword HDUNAME (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.

ASC FITS File Designers Guide 12
ffl The ASC keyword CONTENT is used to store basic information about the content of a file.
ffl The HDUCLAS hierarchy is used by FTOOLS and other software to determine the type of a
file. HDUCLAS gives the origin of the hierarchy, either 'OGIP' or 'ASC'. HDUCLAS1 gives
the highest level filetype, e.g. 'LIGHTCURVE', HDUCLAS2 is more specific, e.g. 'NET',
HDUCLAS3 more specific still, e.g. 'RATE'.
ffl 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
specifies 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.
2.4 Keywords describing the instrumental setup
ffl MISSION is used to define the overall project, e.g. AXAF, HTXS, etc., even when different
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 telescope;
it is used to group together ground cal data with flight data.
ffl TELESCOP is a FITS standard reserved keyword; HEASARC (OGIP/93­013 R12) specifies
the strings used in particular missions. We will use the following values:
Table 2: TELESCOP keyword values
Value Use
AXAF Flight
XRCF/HRMA XRCF
ffl INSTRUME is a FITS standard reserved keyword. HEASARC (OGIP/93­013 R12) specifies
that INSTRUME should refer to the focal plane instrument even when a grating is in place,
i.e., INSTRUME='HRC­S', not INSTRUME='LETGS'. We consider ACIS to be a single
instrument, since any six of its chips can be read out. We consider HRC­I and HRC­S to be
separate instruments.
We use the following values:
Table 3: INSTRUME keyword values
Value Use
ACIS Flight, XRCF
HRC­I Flight, XRCF
HRC­S Flight, XRCF
EPHIN Flight

ASC FITS File Designers Guide 13
PCAD Flight
SPACECRAFT Flight
GENERAL Flight
EPHIN Flight
FPC XRCF
SSD XRCF
HSI 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.
ffl GRATING is introduced to record the gratings. We will use the values LETG and HETG
(and TOGA at XRCF), and (optionally) NONE.
ffl 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­I
HRC­S HRC­S
HRC­SI HRC­S
ACIS­I ACIS­012367 ACIS
ACIS­S ACIS­456789 ACIS
ACA PCAD
GYRO PCAD
SSENSOR PCAD
ESENSOR PCAD
POWER SPACECRAFT
THERMAL SPACECRAFT
GRATING SPACECRAFT
SIM SPACECRAFT
HRMA SPACECRAFT
In fact we hope always to use the mnemonics. Note that DETNAM is not required.
ffl FILTER is used to denote optional filters. We don't have any instruments in flight which use
removable filters, so we won't use this keyword for flight data.
ffl 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.

ASC FITS File Designers Guide 14
ffl 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 reflected
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 configuration, 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:
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
Other SPECIAL
ffl READMODE is an ASC ACIS­specific 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 identification segment of the FITS header would then be:
MISSION = 'AXAF ' / Project
TELESCOP= 'AXAF­I ' / Telescope
INSTRUME= 'HRC­S ' / Instrument
GRATING = 'LETG ' / Grating
DETNAM = 'HRC­S ' / Detector
OBS—MODE= 'POINTING' / Observation mode
DATAMODE= 'SPECTROSCOPIC' / Data mode

ASC FITS File Designers Guide 15
2.5 Exposure Keywords
ffl ONTIME records the sum of all good time intervals. TELAPSE records the difference 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 effects, including spatial ones
such as vignetting, that are specified. 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.
ffl 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 different
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.
ffl DEADAPP = T indicates that dead time corrections have been applied to count rates in the
file. (OGIP/93­003).
2.6 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 different count values per row.
ffl NUMBANDS gives the number of different bands for type II files. (OGIP/93­003)
ffl COUNTS, of type integer, is a table column giving the uncorrected counts. In type II files,
it is an array of NUMBANDS values. (OGIP/92­007, OGIP/93­003)
ffl RATE, of type real, is a table column giving the count rate. In type II files, it is an array
of NUMBANDS values. RATE and COUNTS should not both be present. (OGIP/92­007,
OGIP/93­003)
ffl ERROR, of type real, is a table column giving the error on the COUNTS or the RATE.
(OGIP/93­003)
ffl 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

ASC FITS File Designers Guide 16
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 effect, 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.
ffl 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.7 Source and Background related keywords
These keywords presume the existence of a `source' and a `background', usually defined as spatial
subsets of a set of observational data. The keywords are mostly meaningful for histogram tables
such as PHA files and light curves. The specification of spatial filtering that is applied to the data
may be presented in the format of a REGION table (see ASC­FITS­REGION­1.0).
ffl ERRCOR is used to apply a correction to the errors. The definition 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)
ffl GEOAREA records the geometric area of the detector, usually in sq. cm. (OGIP/93­003).
ffl AREASCAL is an `area scaling factor' which is used to renormalize the histogram. It is an
alternative to the use of an ARF calibration file; usually we use the ARF and set AREASCAL
equal to 1.
ffl 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 definition is value(on­axis) =
value(datafile) / VIGNET. It usually lies between zero and one.
ffl VIGNAPP = T indicates that vignetting corrections have been applied. It is defined in
OGIP/93­003 where it refers specifically to the values of RATE.
ffl BACKFILE is the filename of a background data file associated with the current one.
ffl BACKSCAL is a `background scaling factor' which will be applied to the data in BACKFILE
when it is used with the given dataset.
ffl BACKAPP = T indicates that background subtraction has been performed. As currently
defined it applies specifically to the values of the RATE column (OGIP/93­003).
ffl NPIXSOU and NPIXBACK are used to record the area in pixels of the source and background
regions. (OGIP/93­003).

ASC FITS File Designers Guide 17
ffl CORRFILE is a `correction file', containing a spectrum that is to be subtracted from the
source spectrum.
ffl CORRSCAL is used to scale the data in the correction file.
ffl RESPFILE is the spectral response matrix RMF file to be used with the data.
ffl ANCRFILE is the ancillary response file (effective area versus energy) to be used with the
data.
ffl 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.
ffl SYS ERR is the fractional systematic error on the data in a column called COUNTS or
RATE.
ffl QUALITY is a quality flag describing the data. As a header keyword, it usually is used with
value zero to indicate that all the data is good.
ffl BPIXFILE is the name of the file containing the bad pixel map.

ASC FITS File Designers Guide 18
3 AXAF data product header components
We define the following header components:
ffl CC: Configuration control component
ffl T: Timing component
ffl O: Observation info component
ffl M: Mandatory FITS keywords for HDU type
ffl IC: Image coordinate system keywords (CTYPEn, etc.)
ffl TC: Table coordinate system (TCRPIX) and ranges (TLMIN/TLMAX)
Each of the first three has full and short versions which are defined 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, IC, CC, T, O
Null Primary Aux M, Null CC, Short T, Short O
Table Extn Principal M, TC, CC, T, O
Table Extn Aux M, TC, Short CC, Short T, Short O
Image Extn Aux M, IC, Short CC, Short T, Short O
However, one should apply common sense to the design of FITS headers; keywords that are mean­
ingless in a specific context should be left out.

ASC FITS File Designers Guide 19
3.1 Full configuration 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­1.0 !
COMMENT *********************************************************
COMMENT / Configuration control­­­­­­­­­­­­­­­­­­­­­­­­­­
ORIGIN = 'ASC '
CREATOR = 'xxx ­ Version 0.0'
REVISION= 0 / Processing system revision number
COMMENT $Id: ascfits.tex,v 1.1 1998/03/04 21:50:12 arots Exp arots $
CHECKSUM= '0000000000000000' / ASCII encoded HDU checksum
DATASUM = ' 0' / Data unit checksum written in ASCII
CONTENT = ' ' / What data product
HDUNAME = ' ' / If no EXTNAME
HDUSPEC = 'HRC Level 1 Data Products ICD, Version 1.1' / ICD reference
HDUDOC = 'ASC­FITS­1.0: McDowell, Rots: ASC FITS File Designers Guide'
HDUVERS = '1.0.0 '
HDUCLASS= 'ASC '
HDUCLAS1= ' '
HDUCLAS2= ' '
HDUCLAS3= ' ' / As needed ...
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'.

ASC FITS File Designers Guide 20
3.2 Short configuration control component (Short CC)
COMMENT / Configuration control­­­­­­­­­­­­­­­­­­­­­­­­­­
ORIGIN = 'ASC '
CREATOR = 'xxx ­ Version 0.0'
CHECKSUM= '0000000000000000' / ASCII encoded HDU checksum
DATASUM = ' 0' / Data unit checksum written in ASCII
CONTENT = ' ' / What data product
HDUNAME = ' ' / If no EXTNAME
HDUDOC = 'ASC­FITS­1.0: McDowell, Rots: ASC FITS File Designers Guide'
HDUVERS = '1.0.0 '
HDUCLASS= 'ASC '
HDUCLAS1= ' '
HDUCLAS2= ' '
HDUCLAS3= ' ' / As needed ...
3.3 Configuration control component for null primary HDU (Null CC)
COMMENT / Configuration control­­­­­­­­­­­­­­­­­­­­­­­­­­
ORIGIN = 'ASC '
CREATOR = 'xxx ­ Version 0.0'
CHECKSUM= '0000000000000000' / ASCII encoded HDU checksum
DATASUM = ' 0' / Data unit checksum written in ASCII

ASC FITS File Designers Guide 21
3.4 Full timing component (T)
/ Time information block­­­­­­­­­­­­­­­­­­­­­­­­­
DATE = '1998­01­01T00:00:00' / Date and time of file creation (UTC)
DATE­OBS= '1998­01­01T00:00:00' / TT, with clock correction if CLOCKAPP
DATE­END= '1998­01­01T00:00:00' / 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= 0.0 / 0.0 is the cumulative clock correction
TIMEUNIT= 's '
TIMEREF = 'LOCAL ' / No pathlength corrections
TASSIGN = 'SATELLITE' / Spacecraft clock
CLOCKAPP= T / Clock correction applied
TIERRELA= 1.0E­9 / Short­term clock stability
TIERABSO= 1.0E­4 / Absolute precision of clock correction
TIMVERSN= 'ASC­FITS­1.0' / AXAF FITS design document
TSTART = 0.0 / As in the ''TIME'' column: raw space craft clock;
TSTOP = 0.0 / add TIMEZERO and MJDREF for absolute TT
STARTMJF= 0 / Major frame count at start
STARTMNF= 0 / Minor frame count at start
STOPMJF = 0 / Major frame count at stop
STOPMNF = 0 / Minor frame count at stop
TIMEPIXR= 0.0 / Time stamp refers to start of bin
TIMEDEL = 0.0 / Time resolution of data (in seconds)
3.5 Short timing component (short T)
/ Time information block­­­­­­­­­­­­­­­­­­­­­­­­­
DATE = '1998­01­01T00:00:00' / Date and time of file creation (UTC)
DATE­OBS= '1998­01­01T00:00:00' / TT, with clock correction if CLOCKAPP
DATE­END= '1998­01­01T00:00:00' / TT, with clock correction if CLOCKAPP
TIMESYS = 'TT ' / AXAF time will be TT (Terrestrial Time)
CLOCKAPP= T / Clock correction applied (if false)
TIMEZERO= 0.0 / Clock correction (if not zero)
TIMEUNIT= 's '
MJDREF = 50814 / 1998­01­01T00:00:00 (TT) expressed in MJD (TT)
/ MJD = JD ­ 2400000.5
TSTART = 0.0 / As in the ''TIME'' column: raw space craft clock;
TSTOP = 0.0 / add TIMEZERO and MJDREF for absolute TT

ASC FITS File Designers Guide 22
3.6 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
OBS—ID = 'xxxxxxxxxxxxxxx' / Whatever the convention is ...
MISSION = 'AXAF ' / Mission is AXAF
TELESCOP= 'AXAF ' / Telescope is AXAF
INSTRUME= ' ' / HRC, ACIS, EPHIN, S/C subsystems
DETNAM = ' ' / Detector name
GRATING = 'NONE ' / Grating
OBS—MODE= 'POINTING' / Pointing, slew, or scan
DATAMODE= ' ' / Datamode (varies only for science instr. data)
SIM—X = 0.0 / Position of SIM in mm
SIM—Y = 0.0 /
SIM—Z = ­237.4 /
FOC—LEN = 10065.0 / Assumed focal length, mm
ONTIME = 100.0 / Sum of GTIs
LIVETIME= 98.0 / Ontime multiplied by DTCOR
DTCOR = 0.98 / Dead time correction
/ Source information block­­­­­­­­­­­­­­­­­­­­­­­
OBJECT = ' ' / Source name
RA—NOM = ­100.0 / Nominal pointing
DEC—NOM = ­100.0 / Nominal pointing
ROLL—NOM= ­40.0 / Nominal roll angle, deg
EQUINOX = 2000.0 / J2000.0
RADECSYS= 'ICRS ' / Julian coordinate reference frame
DATACLAS= 'SIMULATED' / If fake data,
/ include this (default is DATACLAS='OBSERVED')
3.7 Short observation info component (short O)
/ Observation information block­­­­­­­­­­­­­­­­­­
OBS—ID = 'xxxxxxxxxxxxxxx' / Whatever the convention is ...
MISSION = 'AXAF ' / Mission is AXAF
TELESCOP= 'AXAF ' / Telescope is AXAF
INSTRUME= ' ' / HRC, ACIS, EPHIN, S/C subsystems

ASC FITS File Designers Guide 23
Appendix 1: EXTNAME/HDUCLAS/CONTENT dictionary
Null primary images are not included. Note that this appendix represents the state of this table at
the time the document was frozen. The table itself is a living document; the current version can
be found at http://hea­www.harvard.edu/¸arots/asc/fits/content.txt.
Data product HDU name CONTENT HDUCLASS HDUCLAS1 HDUCLAS2 HDUCLASS3
L0 Events EVENTS EVT0 OGIP EVENTS ALL
L1 Events EVENTS EVT1 OGIP EVENTS ALL
GTI GTI OGIP GTI ALL
L2 Events EVENTS EVT2 OGIP EVENTS ACCEPTED
GTI GTI OGIP GTI STANDARD
REGION REGION ASC REGION STANDARD
L2 Spectrum SPECTRUM SPECTRUM OGIP SPECTRUM TOTAL COUNTS
GTI GTI OGIP GTI STANDARD
L2 Spectrum SPECTRUM SPEC BKG OGIP SPECTRUM BKG COUNTS
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
GTI GTI OGIP GTI STANDARD
L0 HRC VCDU VCDU HRC VCDU ASC TEMPORALDATA VCDU
L0 ACA VCDU VCDU ACA VCDU ASC TEMPORALDATA VCDU
L0 EPHIN VCDU VCDU EPH VCDU ASC TEMPORALDATA VCDU
L0 HRC gaps TLM GAP TLM GAP ASC TEMPORALDATA TLM GAP
L0 EPHIN gaps TLM GAP TLM GAP ASC TEMPORALDATA TLM GAP
L0 HRC HK HSKPNG HRCHK ASC TEMPORALDATA HKP
L0 HRC Sec. Sci SSCIENCE HRCSS OGIP TEMPORALDATA EVRATE
L0 ACIS Exposure EXR EXR ASC TEMPORALDATA EXPOSURES
L0 ACIS Bias BIAS BIAS OGIP IMAGE BKG
L1 ACIS Exp. Stats EXPSTATS EXPSTATS ASC TEMPORALDATA EXPOSURES
L1 ACIS Mask WINDOW MSK ASC CONFIG WINDOW
L1 ACIS Bad Pix BADPIX BADPIX ASC TEMPORALDATA BADPIX
L1 ACIS Summary SUMMARY ACIS SUMMARY ASC CONFIG ACIS
L1 HRC Summary SUMMARY HRC SUMMARY ASC CONFIG HRC
L1 HRC Livetime DTF DTF ASC TEMPORALDATA DTCOR
L0 EPHIN histo EPHHIST1 EPHHIST ASC TEMPORALDATA SPECTRUM
L0 EPHIN HK EPHHKDTC EPHHK OGIP TEMPORALDATA HKP
L0 EPHIN EIO EPHEIO EPHEIO ASC TEMPORALDATA ?
L0 EPHIN PHA EPHPHA EPHPHA ASC TEMPORALDATA RAWPHA
L0 EPHIN TLM EPHTLMBK EPHTLM ASC TEMPORALDATA TLM
ACA Image ACA IMG 0 ACAIMG ASC TEMPORALDATA ACAIMG
Orbit ephemeris EPHEM EPHEM OGIP TEMPORALDATA EPHEM
HRC gap map ? HRCGAP ASC CORRECTION GAPS
HRC gain map GAIN HRCGAIN ASC IMAGE GAIN
Sky image IMAGE IMG OGIP IMAGE TOTAL
Exposure map EXPMAP EXP OGIP IMAGE EXPOSURE
Source list SRCLIST SRC OGIP SRCLIST
Aspect sol. ASPECT ACASOL OGIP TEMPORALDATA ASPECT
Aspect offsets ASPOFF ASPOFF ASC TEMPORALDATA ASPOFF
Aspect cal ACACAL ACACAL ASC CORRECTION ACACAL
Mission Timeline MTL MTL OGIP TEMPORALDATA TSI
L0 Gyro AXAF GY GYRO OGIP TEMPORALDATA HKP
L0 Earth sensor AXAF ES ESENSOR OGIP TEMPORALDATA HKP
L0 Sun sensor AXAF SS SSENSOR OGIP TEMPORALDATA HKP

ASC FITS File Designers Guide 24
L0 Attitude AXAF AT ATTITUDE OGIP TEMPORALDATA HKP
L0 Earth angle AXAF EA EANGLE OGIP TEMPORALDATA HKP
L0 Power AXAF PW POWER OGIP TEMPORALDATA HKP
L0 Thermal AXAF TH THERMAL OGIP TEMPORALDATA HKP
L0 Status AXAF ST STATUS OGIP TEMPORALDATA HKP
L0 Alignment AXAF AL ALIGNM OGIP TEMPORALDATA HKP
L0 Grating AXAF GR GRATING OGIP TEMPORALDATA HKP
L0 SIM AXAF SIM SIM OGIP TEMPORALDATA HKP
L0 HRMA AXAF HRMA HRMA OGIP TEMPORALDATA HKP
L0 Orbit events AXAF OEVT ORBEVTS OGIP TEMPORALDATA HKP
L0 Telemetry temp AXAF TT TLMTEMP OGIP TEMPORALDATA HKP
Raw telemetry AXAF TLM TLM ASC TEMPORALDATA TLM

ASC FITS File Designers Guide 25
Appendix 2: Allowed units from OGIP/93­001
Table 8: OGIP/93­001 SI prefixes
HEASARC Prefix SI prefix Value
y yocto (y) 10 \Gamma24
z zepto (z) 10 \Gamma21
a atto (a) 10 \Gamma18
f femto (f) 10 \Gamma15
p pico (p) 10 \Gamma12
n nano (n) 10 \Gamma9
u micro (¯) 10 \Gamma6
m milli (m) 10 \Gamma3
c centi (c) 10 \Gamma2
d deci (d) 10 \Gamma1 (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 Prefix?
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 26
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 flux Y
G gauss N
count counts N
photon photons N
pixel pixel N
barn barn N
chan detector channel N
bin bin N
voxel 3­D pixel N
byte byte N