[fitsbits] [mhvk at astro.utoronto.ca: Question about FITS format for logarithmic units]

[Lucio Chiappetti]

On Tue, 10 Dec 2013, Rob Seaman wrote:

> But one reason units are not discussed more extensively in the FITS 
> standard is that the issue is broader than FITS usage.  The IVOA (an 
> activity of the IAU) is working on the problem of expressing units:

I second the statement by Rob (not only in the context raised by Marten, 
but in wider contexts some of you may be aware of). One should not 
overload FITS with expectations that go beyond it.

I hadn't followed the VO work on the matter of units, but I'd expected 
them to do something about it. After all VO should "wrap" FITS datasets as 
well as other kinds of dataset. Defining a general way to handle units is 
an ambitious goal. It might not be a chance that the IVOA standard quoted 
by Rob is dated Oct 2013 when the VO started long ago ... :-)

In general I would say that, designing a package, one should distinguish 
between human readable or computer readable information. The first is more 
or less of "commentary" nature, and/or requires the intervention of a 
human user or operator. Note that FITS provides ways to indicate units in 
keywords (BUNIT TUNITn) as well as in keyword comments (section 4.3.2).

Having instead a package capable of reading computer readable unit 
information and deal with it (e.g. when operating between columns or 
between images) is an ambitious goal.

In this respect it is also a difficult goal, if one wants the package to 
be able to read GENERIC (FITS or not) files. Including FITS files created 
in the past, and conforming to the standard (Once FITS forever FITS) but 
maybe with partial information, not exploiting all details of the 
standard, not following the non-compulsory recommendations, or even 
deviating from it. I guess many people will for instance use CGS units 
like erg/cm2/s or even customary ones like erg/cm2/s/A (and I willingly 
use here the "forbidden" multiple-slash notation !)

So possibly a package should NOT have as goal the capability to deal with 
general and generic FITS files of arbitrary origin, but define a local 
convention (taking e.g. a subset of an existing convention) and stick to 
it for files PRODUCED by the package.  Having instead "converters" (maybe 
in form of custom scripts) to "normalize" external files to such 
convention BEFORE INPUT.

Also talking in general, I note that when one talks about quantities and 
their units, one might need to distinguish different practical concepts.

- One is the NAME of the quantity. This can be e.g. a database column
   name, or a FITS table column name (TTYPEn), or a symbol in a printed
   table, or a mathematical symbol in a formula, or a variable in a
   programming language. This name is likely to be subject to limitations
   (for instance the recommendations on TTYPEn do not allow imbedded blanks
   or parentheses, column names in mysql shall conform to mysql syntax
   etc.).

   This name cannot therefore convey all information. Let us say we have
   a flux, which can be measured at the Earth (with interstellar
   absorption), or at the source (unabsorbed). Or we have a luminosity,
   but this can be a 2-10 keV luminosity, a 1000-3000 A luminosity, a
   bolometric luminosity. More below about magnitudes ...

   A thing like TTYPEn is intended to be computer-readable (to extract
   the given column, or to operate among columns)

- so a different kind of information is a "description", which is
   intended to be human readable, and may be a complex string like

   '0.5-2 keV flux at the Earth' or 'log 2-10 keV luminosity'

   This information should go in some form of comments.
   And perhaps be used in table captions or notes or plot titles.

- the units are another thing, they fit more or less nicely in FITS kwds
   like TUNITn.

   In this respect I won't consider "log" to be part of the units ...
   since quantities are usually dimensional, and log operates only on
   dimensionless arguments (see example in section 4.3.1)

   I would imagine a caption like 'log luminosity [erg/s]' or
   'log 2-10 keV luminosity [erg/s]'

- plot captions are in fact another things. The unit indication should be
   appended to the caption, which may not be too long, and can perhaps use
   a mathematical symbol with subscripts and superscripts.

   On the other hand, however short it might be, it shall be complete (for
   instance in sort-of colour-colour diagrams it should report the band
   the flux or magnitude is measured in)

On Tue, 10 Dec 2013, Marten van Kerkwijk wrote:

> The background to this request actually is not directly related to FITS, 
> but rather to an attempt to introduce functional units in astropy

   What I call an ambitious goal. See comment above.

> The later ones concern magnitudes with a unit; for (4), I should add 
> that I very much agree that "mag(AB)" would be far clearer than what I 
> give there, but obviously no current FITS reader would understand it (I 
> do prefer it greatly over "AB mag"

> (3) If I wanted to represent magnitudes *with* a unit, such as AB
>   magnitudes, what would be the recommended format?  I only noticed
>   "mag" without units, but is "mag(unit)" allowed?

Well, I won't call them "magnitudes with a unit" but more "magnitudes with 
a method" (e.g. AB or Vega), and of course there are also "magnitudes 
with a band" (UVBRI JHK u*g'r'i'z' etc. etc.), and of course relative or 
absolute magnitudes.

As such they belong to the description or caption.
E.g. "R (AB) magnitude [mag]"

-- 
------------------------------------------------------------------------ 
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy) For 
more info : http://www.iasf-milano.inaf.it/~lucio/personal.html