From dishfits-request Sun Feb 26 05:49:23 1995 X-VM-Summary-Format: "%n %*%a %-17.17F %-3.3m %2d %4l/%-5c %I\"%s\"\n" X-VM-Labels: nil X-VM-VHeader: ("Resent-" "From:" "Sender:" "To:" "Apparently-To:" "Cc:" "Subject:" "Date:") nil X-VM-Bookmark: 1 X-VM-v5-Data: ([nil t nil nil nil nil nil nil nil] ["2832" "Sun" "26" "February" "1995" "21:49:11" "EST" "Ray Norris" "rnorris@atnf.csiro.au" nil "72" "Re: GBT use of FITS for single dish data" "^From:" nil nil "2" nil nil (number " " mark "U Ray Norris Feb 26 72/2832 " thread-indent "\"Re: GBT use of FITS for single dish data\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-CV/1.8) id AA16705; Sun, 26 Feb 95 05:49:23 EST Return-Path: Message-Id: <9502261049.AA19577@brogar.rp.CSIRO.AU> From: rnorris@atnf.CSIRO.AU (Ray Norris) Sender: dishfits-request@fits.cv.nrao.edu To: dishfits@fits.cv.nrao.edu, bgarwood@sngldsh.cv Subject: Re: GBT use of FITS for single dish data 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