Subject: Re: GBT use of FITS for single dish data

From: [email-masked] (Ray Norris)
Date: Sun, 26 Feb 95 21:49:11 EST

Hi Bob and everyone else

Thanks for starting the exploder/newsgroup discussion going. Sorry I've
been so tardy in contributing.

Before we get involved in details of what keywords to use etc, I have a
basic question, the answers to which seem implicit in your email, but
I'm haven't heard much discussion of it (perhaps there's been a
discussion in another forum). 

How do we store a series of spectra obtained with a telescope? It seems
there are several ways:

1) Put each observation as a row in a binary table. However, you won't
know how many observations there will be until you finish, so you have
to go back and overwrite the header. Maybe this isn't a problem if all
your data is on disk, but it precludes writing out data in real-time to
tape or whatever. Despite this drawback, this seems to be the obvious
way, and I assume this is what is implicit in NRAO thinking.

2) Write a new file for each observation. I gather this is already used
by several groups, but you end up with an enormous file management
problem.

3) As (2), but append the files into one long file. This is also used
by some groups, but isn't standard FITS.

4) Create a new table for each observation. This seems to have some
advantages over the other methods, but I haven't heard any discussion
of it.

So how do people feel about these alternatives?

I have a couple of other questions/comments:

1) A common observing mode at Parkes (and I assume other instruments)
is to observe two transitions simultaneously (e.g. megamaser
observations at HI 1420 MHz and OH 1665 MHz).  Unfortunately many of
the FITS header keywords suggested (e.g. TSYS, RESTFREQ, etc) would be
good for only one of these bands, and so it would not be appropriate to
put them in the FITS header.

The alternatives are 

a) Create a separate file for each band. I don't
like this because then you can't do all the editing, calibration, etc
in one go, quite apart from increasing the file handling problems.

b) Create separate keywords for each band (RESTFRQ1, RESTFFRQ2, etc).
Ugh!

c) Put the keywords as columns in the binary tables

d) Put the keywords as headers for the tables, and have separate tables
for each band. This seems to be the most sensible way to go.

2) A related problem is that of multi-beam feeds (e.g. the 13-beam HI
feed now being built for Parkes). Again, we need a different Tsys etc
for each beam. Again, maybe a separate table for each beam is needed.

3) Another related problem is the use of arrays of different lengths,
which others (e.g. Bob) have already noted. Typically in multi-band
observations you might observe with different numbers of channels in
each band, and different bandwidths, to achieve comparable velocity 
resolution. So I for one would urge that we try to incorporate 
support for variable length arrays.

Cheers

Ray