NOTICE:

This Legacy journal article was published in Volume 4, February 1994, and has not been updated since publication. Please use the search facility above to find regularly-updated information about this topic elsewhere on the HEASARC site.

Specification of Physical Units

Ian M. George & Lorella Angelini

HEASARC


OGIP Memo OGIP/93-001 Version: 1993 Aug 06

Summary

A list of character strings specifying the basic physical units used within OGIP FITS files is given. Rules and guidelines on the construction of compound units are also outlined.

1 Introduction

In order to facilitate the use of FITS datasets by downstream s/w and users, it is clearly highly preferable that a common set of character strings are used throughout all files and software to specify the physical units in which the data are stored. This memo lists those currently approved for use within the OGIP and should be strictly adhered to[2].

In Section 2 we give a list of character strings specifying the basic physical units allowed within OGIP FITS files, including guidelines on the use of decimal multiples and submultiples of units. Section 3 provides a number of rules and guidelines on the construction of compound units, and a number of examples are given in Section 4. It should be noted that within the framework provided here, the ultimate responsibility for choosing sensible and convenient unit strings lies with authors of FITS datasets.

Any comments or suggestions (especially if you have a requirement for units not covered by this memo) should be e-mailed to the authors (george@heasrc.gsfc.nasa.gov and/or angelini@heasrc.gsfc.nasa.gov).

2 Basic Units

In line with IAU recommendations, SI units should be adopted for all physical quantities with the exception of a small number of special units more convenient for astronomy. The character strings specifying the basic units allowed for use within the OGIP are listed in Tables 1 and 2, along with the allowed prefixes for multiples and submultiples listed in Table 3. Note that all strings are CASE SENSITIVE.

When used as the value of the TUNITnnn keyword in the header of a FITS extension, it is recommended that the first character of the string is placed immediately after the opening quote in the value field (i.e. placed in column 12 of the 'card image').

2.1 IAU-recommended Units

Table 1 lists the 7 base SI units regarded as dimensionally independent and 2 supplementary units for plane and solid angles, along with the 15 derived units (formed by combining base and supplementary units) with unique symbols recognized by the IAU. All units are given for completeness, though several are likely to be of little use to X- and gamma-ray astronomy. It can be seen that in the majority of cases, the character string is identical to the IAU-recognized symbol for the quantity[3]. The only exception is electric resistance (with symbol omega, but string ohm). Finally it should be noted that despite IAU recommendations the measurement of plane angles in radians may often be considered inconvenient within astronomy. Thus the use of decimal degrees is also allowed (e.g. Table 2).

Table 1

2.2 Additional Astronomical Units

Unfortunately, a. number of the IAU-recommended units listed in Table 1 are somewhat inconvenient for some astronomical applications. Thus the OGIP-recommended strings for such quantities. Again, in most cases the character string is identical to the IAU-recognized symbol for the quantity. The only exceptions are:

  • degrees of arc (with symbol degree but string deg)
  • angstrom (with symbol Å, but string angstrom so as not to be confused with ampere, A).
  • the character string yr is preferred over the IAU-recognized symbol (a) since it is the same
    as the symbol used for this quantity in most astronomical journals, and in common usage.
  • arcsec & arcmin since the symbols of " and ' may lead to confusion

Finally the 'crab' was commonly used in the early days of X-ray astronomy, and is represented in Table 2. However this unit (or more commonly the 'millicrab') should be avoided wherever possible as the conversion to more standard specifications of flux density is a function of the spectrum of the source (relative to that of the Crab). Strictly speaking, the same is true regarding the use of stellar 'magnitudes' (mag).

Table 2

2.3 Prefixes for Multiples & Submultiples

The IAU-approved list of prefixes to note decimal multiples and submultiples of units are listed in Table 3, along with the corresponding character strings. It can be seen that the character is the same as the IAU-approved symbol for the prefix with the exception of micro (10-6), which has the symbol mu but character u. However, with the exception of centi (10-2), the OGIP strongly recommends the use of prefixes which are powers of 3.

Thus strings to specify decimal multiples submultiples of the units given in Table 1 can be formed[4] by preceding the listed character string by the relevant prefix character from Table 3. Decimal multiples submultiples of the units listed in Table 2 should NOT be used, with the exception of electron volt (eV), jansky (Jy), parsec (pc), and crab (Crab, for which millicrab, mCrab ONLY is allowed). Compound prefixes (e.g. ZYerg for 1045 erg) should never be used. The result is regarded as a single unit string when constructing compound units (see Section 3). It should be noted that the use of these standard prefixes greatly increases the case sensitivity of the resultant string.

Table 3

3.1 Basic Syntax

A compound unit is considered to be formed by a series of sub-strings of component units & mathematical operations. Each of these sub-strings must be separated by at least one space or a mathematical operator (* or /). In line with the rules given below, all such sub-strings should be considered in a multiplicative sense unless beginning with a slash (/), or enclosed within one or more pairs of brackets.

3.1.1 Multiplication

Multiplicative units can be specified either:

  • by simply using one or more preceding spaces
    e.g. 'str1 str2'
    (The recommended method)
  • by the use of a single asterix (*) with or without one or more spaces on either side
    e.g. 'str1 * str2'
    (This syntax should never be used preceding a sub-string which starts with a slash - see Section 3.1.2).

3.1.2 Division

Units which form the denominator of a compound expression can be specified either:

  • by using a slash (/) with or without one or more spaces on either side
    e.g. 'str1 /str2' or 'str1 / str2' or 'str1/str2'
    If such a syntax is used, it is recommended that no space is included between the slash and the unit string.
  • by raising a multiplicative unit to a negative power (see below)
It should be stressed that the slash character only effects the sub-string it immediately precedes. Thus unless brackets are used, subsequent sub-strings which also form part of the denominator of the compound expression must also be preceded by a slash.
e.g. 'str1 /str2 str3' is equivalent to 'str1 str3 /str2'
whilst 'str1 /str2 /str3' is equivalent to 'str1 /(str2 * str3)'

3.1.3 Raising to Powers

A unit string raised to the power y is specified

  • by using two asterixes (**) followed by the index enclosed within round brackets and with no preceding or intervening spaces.
    e.g. 'str1**(y)' or 'str1**(-y)'

However, if y is positive, then the brackets need not be included, but a following space is recommended if additional sub-strings follow.

3.1.4 The use of brackets

Any number of pairs of round brackets () may be used within the string for a compound unit in order to prevent ambiguities. As described within this section, a number of rules always/often require their use. However, it is suggested that conservative use is made of such pairs of brackets in order to minimize the total length of compound strings. (It should be remembered that a maximum of 68 characters are allowed in the card image of keywords.)

3.2 Avoidance of underflows & overflows

The inclusion of numerical factors within the unit string should generally be avoided (by the use of multiples and/or submultiples of component basic units; Section 2.3).

However, occasionally it may be preferable to include such factors on the grounds of user-friendliness and/or to minimize the risk of computer under- or overflows. In such cases, the numerical factor can simply be considered a basic unit string and all rules guidelines given in Section 2 apply.

It should be remembered, however, that the use of numerical (scaling) factors within the unit string can result in additional overheads in the parsing/interpretation of the string if the string is used for any purpose other than as a 'label'. The inclusion of numerical factors should therefore be avoided wherever possible, and should never replace the use of the TSCALnnn keyword.

The following additional guidelines are suggested:

  • the numerical factor should precede any unit strings

  • only powers of 10 are used as numerical factors

A prime example is astronomical luminosities, and examples of this case along with a number of more complex examples is given in Section 4.

3.3 Mathematical Operations & Functions

The character strings denoting mathematical operations are listed in Table 4. It should be noted that the (round) brackets are mandatory in all cases in which they are included in the table (with the exception of raising units to positive powers -- see Section 3.1.3).

Table 4

4 Examples

For illustration, example strings representing a number of compound units are given below, along with a limited number of alternatives. It should be noted that within the rules given in Section 3, the number of spaces between individual unit sub-strings is left a matter for personal preference.

  1.  STRING = 'count /s'                                       (recommended)
      Meaning: counts per second
      Alternatives:
      STRING = 'count/s'
      STRING = 'count s**(-1)'
      STRING = 'count  / s'
      STRING      count    /s                                   (discouraged)

2. STRING = '/pixel /s' (recommended) Meaning: per pixel per second Alternatives: STRING = '/(pixel * s)'

3. STRING = 'count /m**2 /s /eV' (recommended) Meaning: counts per square metre per second per electron volt Alternatives: STRING = 'count m**(-2) * s**(-1) * eV**(-1)' STRING = 'count /(m**2 * s * eV)'

4. STRING = 'erg /pixel /s /GHz' (recommended) Meaning: ergs per pixel per second per gigahertz Alternatives: STRING = 'erg /s /GHz /pixel' STRING = 'erg /pixel /(s * GHz)' (discouraged)

5. STRING = 'keV**2 /yr /angstrom' (recommended) Meaning: square kiloelectron volts per year per angstrom Alternatives: STRING = '10**(10) keV**2 /yr /m' (discouraged) STRING = '(10**2 MeV)**2 /yr /m' (strongly discouraged) 6. STRING = '10**(46) erg /s' (user-friendly) Meaning: 1046 ergs per second Alternatives: STRING = '10**46 erg /s' STRING = '10**(39) J /s' STRING = '10**(39) W' (recommended) STRING = '10**(15) YW' STRING = 'YJ /fs' (for the purist) 7. STRING = '10**(-7) J /cm**2 /MeV' Meaning: 1O-7 joules per square centimetre per megahertz Alternatives: STRING = '10**(-9) J m**(-2) eV**(-1)' STRING = 'nJ m**(-2) eV**(-1)' STRING = 'nJ /m**2 /eV' (recommended) 8. STRING = 'sqrt(erg /pixel /s /GHz) (recommended) Meaning: The square root of Example 4 Alternatives: STRING = '(erg /pixel /s /GHz)**(O.5)' STRING = '(erg /pixel /s /GHz)**(1/2)' (discouraged) STRING = 'erg**(0.5) pixel**(-0.5) s**(-0.5) GHz**(-O.5)' (discouraged) 9. STRING = 'log(photon /m**2 /s /Hz) (recommended) Meaning: The common log of a photon flux density Alternatives: STRING = 'log( photon /m**2 /s /Hz )' (and those associated with the unit substrings) 10. STRING = 'sin( /pixel /s)' (recommended) Meaning: The sine of Example 2 Alternatives: None (except those associated with the individual unit sub-strings) 11. STRING = '(count /s) (/pixel /s)' Meaning: Example 1 multiplied by Example 2 Alternatives: STRING = '(count /s) * (/pixel /s)' STRING = 'count /pixel /s**2' (recommended) 12. STRING = 'log(photon /cm**2 /s /Hz) /(sin( /pixel /s))' (recommended) Meaning: Example 9 divided by Example 10 Alternatives: STRING = 'log(photon /cm**2 /s /Hz) (sin( /pixel /s) )**(-1)'(discouraged)

Acknowledgments

We would like to thank the numerous people who have contributed valuable comments to the various drafts of this memo, and in particular Don Wells, Clive Page, Bill Pence & Jonathan McDowell.


Next Proceed to the next article Previous Return to the previous article

Contents Select another article




HEASARC Home | Observatories | Archive | Calibration | Software | Tools | Students/Teachers/Public

Last modified: Monday, 19-Jun-2006 11:40:52 EDT