Subject: logical variables

From: jwright at cfht.hawaii.edu (Jim Wright)
Date: Sat, 19 Sep 1992 00:19:27 GMT

An excerpt from the NOST 100-0.2f FITS Draft Standard, dated May 14, 1991:

| 5.3.2.2 Logical Variable
|
| If the value is a logical constant, it shall appear as a T or F in
| column 30.

(This is the entire section !)

I would like to initialize all cards to values that show the card has not
yet been filled out, and then put in the real values.  For example,

LAMPON   =                     ?          / lamp on during exposure

And then at exposure time fill out the card with "T" or "F".  This way it
is very obvious if the card contains valid data or not.  Is this acceptable?

Yes, not putting the card in until the time it is filled out is best.  But
that is not an option for us.  The entire FITS header is built before an
exposure and individual cards are given their values during the course of
the exposure.

--
Jim Wright
jwright at cfht.hawaii.edu
Canada-France-Hawaii Telescope Corp.

---

From: leb at Hypatia.gsfc.nasa.gov (Lee E. Brotzman)
Date: Sat, 19 Sep 1992 04:29:52 GMT

>(This is the entire section !)
                     ^^^^^^^
Actually its a sub-sub-sub-section and this is a standard, not human-readable
text.  :-)

>is very obvious if the card contains valid data or not.  Is this acceptable?

The 'T' in FITS is for Transport.  Until you try to transport the FITS file,
anything goes.  Your internal processing of the FITS file, and especially
intermediate results, are not important.  Do whatever is the most efficient and
reasonable for your application.  If you try to transport the FITS header with
question marks instead of valid boolean 'T' or 'F', however, FITS readers the
world over will throw up all over your file.

I'm working on a program that extracts records from one FITS table and puts them
into another FITS file.  Obviously, I don't know the number of records I'm
going to extract until I am done, so I put a 0 in the NAXIS2 record in the
extension header.  Then when I have finished the extraction I reposition the
file pointer to the appropriate record position and fill in the proper number
of records that were extracted.  The intermediate file is in violation of the
standard, and if the program aborted for some reason before it filled in the
NAXIS2 record, and I tried to palm off the file as correct, I would be
violating the standard. 

The bottom line is, use templates for filling out FITS headers, make sure you
complete the template, and perhaps include a post-processing step that will
strip out -- with appropriate warning messages -- unfilled records.

--
-- Lee E. Brotzman                    Internet:  leb at hypatia.gsfc.nasa.gov
-- Hughes STX                         DECNET:    NDADSA::BROTZMAN
-- National Space Science Data Center BITNET:    ZMLEB at GIBBS
-- NASA Goddard Space Flight Center

---

From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
Date: Sun, 20 Sep 92 13:44:54 ITA

>The 'T' in FITS is for Transport.  Until you try to transport the FITS file,
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>anything goes.  Your internal processing of the FITS file, and especially

  The example above indicates one specific case of a limitation with the
  use of FITS files other than for transport, indeed |
  This shows up in a more extreme case if not only the values, but the
  number of keywords in a file header is unknown at the moment of the
  creation of the file |
  The point is that the FITS header is a true header (i.e. comes in front
  of the data), and once written it cannot be extended (one could advocate
  reserving empty space in the header, as e.g. Bill Pence's FITSIO allows,
  but even the amount to be reserved may be not known a priori)

  There is also another case, assume I want to modify a file in place
  (say I want to multiply all values in a column of a BINTABLE by an amount,
  e.g. converting angular coordinates to microns in the focal plane multi-
  plying by a platescale) AND I want to record the change ADDING more
  keywords to the header. If my work file is FITS I cannot do it, unless
  I write an entirely new file, or I shift all data records (which is
  equivalent to rewriting all).

  The only way out to have an extendable and modifiable header is to have
  it stored either at the end of the file (the solution I prefer), or
  elsewhere (like IRAF .imh and .pix files).

  Far from diminishing the enormous value of FITS as a TRANSPORT standard,
  this is however a very important reason to support the traditional view
  (e.g. IRAF's and MIDAS's) that work files are read from FITS into a
  native format for manipulation and written out to FITS for export.

-----------------------------------------------------------------------------
       A member of  G.ASS : Group for Astronomical Software Support
-----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR Milano        |         U N I C U I Q U E
via Bassini 15 - I-20133 Milano - Italy    |          System  Manager
Internet: LUCIO at IFCTR.MI.CNR.IT            |           FORTUNAE SUAE
Decnet:   IFCTR::LUCIO (39610::LUCIO)      |
Bitnet:   EXOSAT at IMISIAM                   |
-----------------------------------------------------------------------------

---

From: tjp at eccles.caltech.edu (Tim Pearson)
Date: 20 Sep 1992 10:36 PST

>LAMPON   =                     ?          / lamp on during exposure

If a FITS keyword has a logical value, it must be either T or F. 
However, there is nothing in the standard that says that the keyword 
LAMPON must have a logical value. If you don't know whether the lamp is 
on or off, you could put

 LAMPON   =  'unknown'                    / lamp on during exposure

This would be legal FITS and should be accepted by your FITS reader.
Your FITS reader might have trouble mapping a string value into a 
logical variable in your analysis program, but that is not a FITS 
problem.

Personally, I prefer to avoid logical values. To record status like 
this, I would use

 LAMP     = 'ON'
 LAMP     = 'OFF'
 LAMP     = 'UNKNOWN'

for example. This allows other unthought-of possibilities to be added
later, e.g.,

 LAMP     = 'GREEN'

Tim Pearson, Astronomy Dept 105-24, Caltech, Pasadena, California 91125, USA
Internet:                  TJP  at  Deimos.Caltech.Edu, Pearson_T  at  caltech.edu
Telephone:                 +1 818 356-4980
FAX:                       +1 818 568-9352

---

From: pence at heawk1.gsfc.nasa.gov (William Pence)
Date: Mon, 21 Sep 1992 20:55:40 GMT

Lucio Chiappetti <lucio at ifctr.mi.cnr.it> previously wrote:

>  use of FITS files other than for transport, indeed 
>  creation of the file
       (lines editted out)
>  native format for manipulation and written out to FITS for export.

One of the major recent enhancements to FITSIO, which was first
introduced in version 3.20 (released in March 1992) is the ability to
dynamically increase the number of keywords in the header of a
previously written FITS file.  Thus,  users/programmers using FITSIO do
not have to worry whether there is enough space in the header before
writting new keywords.  FITSIO will keep track of how much space is
available (users may preallocate extra space when the file is created).
If there is no more room, then FITSIO will shift all the following
data records, including any additional extensions in the FITS file, and
append a new empty 2880 byte block onto the header.  This all takes
place transparently to the user/programmer.  This shifting of data
obviously requires some overhead, but our experience in using FITS
files as an internal data processing format indicates that this does not
cause a significant impact.  

Here at the HEASARC we have spent the last year developing a
comprehensive package of programs called FTOOLS for manipulating FITS
format files.  (The first public release of the package is planned for
the end of next month).  We have accumlated a lot of experience
processing FITS files which shows, contrary to the conservative view
that FITS is only a transport format,  that FITS is an excellent
analysis format in its own right which has many advantages.  The
self-documenting nature of the headers, the flexibility and storage
efficiency of the new binary table extension format, and most
importantly, the ability to simply copy any FITS files to any type of
machine without having to worry about the internal machine data
formats, makes FITS an ideal format for processing data in today's
hetrogeneous computer processing environments.

-Bill Pence
pence at tetra.gsfc.nasa.gov
HEASRC::PENCE