From dwells Thu Jan 12 13:34:53 1995 Status: RO X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1166" "Thu" "12" "January" "1995" "13:34:51" "EST" "Don Wells" "dwells" nil "27" "Dishfits test#1" "^From:" nil nil "1" nil nil (number " " mark " Don Wells Jan 12 27/1166 " thread-indent "\"Dishfits test#1\"\n") nil] nil) 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: 7 Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.5) id AA06940; Thu, 12 Jan 95 13:34:53 EST Return-Path: Message-Id: <9501121834.AA06934@fits.cv.nrao.edu> From: dwells (Don Wells) Sender: dishfits-request@fits.CV.NRAO.EDU To: dishfits Subject: Dishfits test#1 Date: Thu, 12 Jan 95 13:34:51 EST Dear subscribers to the 89-90 'dishfits' exploder, I have reactivated the 'dishfits' Email exploder, at the request of Ray Norris (ATNF) and Bob Garwood (NRAO). The old Email distribution has been updated, and some new names have been added. A few of the old names have been deleted, but we decided to err on the side of caution in the deletion process. So, if you are no longer interested in discussions of FITS matters in the context of single-dish radio astronomy, reply to this message (send the reply to 'dwells' or 'dishfits-request') with a statement to that effect and I will delete your address from the list. If you do want to participate in the discussions, there is no need to reply. If any of the addresses in the list 'bounce', I will send one or more additional test messages to verify addresses. Full operation of the exploder is expected within the next ten days. Regards, Don -- Donald C. Wells Associate Scientist dwells@nrao.edu http://fits.cv.nrao.edu/~dwells National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road, Charlottesville, Virginia 22903-2475 USA From dishfits-request Thu Jan 26 15:23:18 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["5474" "" "26" "January" "1995" "20:23:04" "GMT" "Don Wells" "dwells@nrao.edu" "" "131" "dishfits exploder, adass.fits.dishfits newsgroup" "^From:" nil nil "1" "1995012620:23:04" "dishfits exploder, adass.fits.dishfits newsgroup" (number " " mark " Don Wells Jan 26 131/5474 " thread-indent "\"dishfits exploder, adass.fits.dishfits newsgroup\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.7) id AA27755; Thu, 26 Jan 95 15:23:18 EST Return-Path: Message-Id: Organization: nrao Path: solitaire.cv.nrao.edu!news.cv.nrao.edu!dwells Newsgroups: adass.fits.dishfits,adass.admin From: dwells@nrao.edu (Don Wells) Sender: dishfits-request@fits.cv.nrao.edu To: dishfits@fits.cv.nrao.edu Subject: dishfits exploder, adass.fits.dishfits newsgroup Date: 26 Jan 1995 20:23:04 GMT Dear 'dishfits' friends, After discussions with Bob Garwood, Pat Murphy, Doug Tody, Ray Norris, Jeff Uphoff and the readers of newsgroup adass.admin, I have decided to activate newsgroup adass.fits.dishfits, and establish a gateway to connect it to exploder dishfits@nrao.edu. This message is being posted to the new newsgroup adass.fits.dishfits, as well as to group adass.admin (in order to alert the adass.* community to the existence of the new newsgroup). The adass.* hierarchy of newsgroups was established by Doug Tody and others to provide a home in USENET for astronomy discussions for which it is not practical to execute the formal USENET newgroup-creation voting procedure. The argument in favor of the adass.* hierarchy is that it will not be an anarchistic environment like the alt.* hierarchy, and therefore is less likely to be bothered by non-professional people. The argument against adass.* is that astronomy sites must make a deliberate effort to carry these newsgroups in their repertoire (of course, alt.* is not carried by many astronomy sites, as a matter of policy). I myself regard the choice of newsgroup adass.fits.dishfits (instead of, for example, alt.sci.astro.dishfits) as an experiment which should be tried. I personally prefer reading newsgroups to reading Email, because the general subjects are separated into newsgroups (categories) instead of being jumbled in the mailbox, because of the "threading" action of my newsreader (I use GNUS) and because I can use "killfiles" to suppress traffic which does not interest me. I expect to read dishfits traffic by reading adass.fits.dishfits. Any of you who also prefer to read adass.fits.dishfits, and are able to receive it, can simply send Email to me (or to 'dishfits-request@nrao.edu') asking to unsubscribe from the dishfits distribution list. -*- I have activated the dishfits exploder, and will leave it active. I append the current distribution list (including its URL); send address corrections and requests to be added to or dropped from the list to 'dishfits-request@nrao.edu' (which is currently aliased to me). Send postings to 'dishfits@nrao.edu' or post to newsgroup 'adass.fits.dishfits'; traffic posted to either service will appear in the other service (i.e., they are connected by a bi-directional gateway). All traffic posted will be archived in files with URLs of the form ftp://fits.cv.nrao.edu/fits/traffic/dishfits/dishfits.95xx (the current active file is dishfits.9501). The subdirectories dishfits.89 and dishfits.90 in that directory contain traffic from the first dishfits exploder. I have created a directory to hold dishfits-related documents: ftp://fits.cv.nrao.edu/fits/documents/drafts/dishfits/ Bob Garwood will be responsible for maintenance of this directory. Regards, -Don -=-=- ftp://fits.cv.nrao.edu/fits/traffic/dishfits/dishfits.dis -=-=- adass.fits.dishfits Chris Phillips Ron Ekers Neil Killeen Peter te Lintel Simone Magri Henrietta May Ray Norris Euan Troup Tom Wilson S. Guilloteau Thierry Forveille Butler Burton Preben Grosbol Rein Warmels SEST Roy Booth Michael Olberg Lars Lundahl Jim Cohen Paul Harrison Pat Wallace Malcolm Curry Bob Wilson Jeff Mangum Bill Peters Betty Stobie Tom Phillips Dan Harris Mary A. Fuka Henry Matthews Richard Prestage James Scobbie Remo Tilanus John Ball Barry Geldzahler Willem Baan Chris Biemesderfer George Seielstad Dana Balser Aaron Benett Bob Brown Mark Clark Bill Cotton Darrel Emerson Rick Fisher Bob Garwood Frank Ghigo Eric Greisen Phil Jewell Glen Langston Harvey Liszt Jay Lockman Ron Maddalena Pat Murphy Bob Payne Bob Vance Don Wells Al Wootten Bob Hanisch Peter Schloerb Barry Schlesinger -- Donald C. Wells Associate Scientist dwells@nrao.edu http://fits.cv.nrao.edu/~dwells National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road, Charlottesville, Virginia 22903-2475 USA From dishfits-request Thu Jan 26 15:37:23 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3261" "" "26" "January" "1995" "20:36:54" "GMT" "Bob Garwood" "bgarwood@sngldsh.cv" "" "69" "Single Dish FITS" "^From:" nil nil "1" "1995012620:36:54" "Single Dish FITS" (number " " mark " Bob Garwood Jan 26 69/3261 " thread-indent "\"Single Dish FITS\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.7) id AA27852; Thu, 26 Jan 95 15:37:23 EST Return-Path: Message-Id: Organization: nrao Path: solitaire.cv.nrao.edu!news Newsgroups: adass.fits.dishfits From: bgarwood@sngldsh.cv (Bob Garwood) Sender: dishfits-request@fits.cv.nrao.edu To: dishfits@fits.cv.nrao.edu Subject: Single Dish FITS Date: 26 Jan 1995 20:36:54 GMT Greetings, Since I was one of the first folks to suggest last December that the dishfits exploder (now also a newsgroup in the adass hierarchy) be reactivated, I should take a few moments to provide some background. First, let me introduce myself to those that don't know me. I'm Bob Garwood and I'm the scientific programmer at NRAO responsible for (among other things) the care and feeding of UniPOPS - our single dish analysis package. In late 1989 there was a meeting (which was attended by a number of people on the dishfits exploder) in Green Bank to consider the creation of a standard data transport and interchange format for "single-dish" (i.e. non-synthesis) radioastronomy data. The then-new FITS binary tables format (known at the time as FITS "3-D" tables) was adopted as the standard along with a convention describing the use of that emerging standard for holding single dish data. Since that meeting a number of things have occured, with little communication between the various participants at that meeting. (1) The FITS binary tables format has become standardized. The standard differs somewhat from it's state as of the '89 meeting. (2) Hierarchical FITS name-space never occured. (3) An initial attempt to implement the `89 agreement has been in use within UniPOPS for the last 2-3 years. (4) Other groups have expressed an interest in single dish FITS (SDF), especially within the last few months. (5) I strongly suspect that NRAO is not the only institution that has experimented with some form of single dish FITS based on the `89 meeting. It was (4) that prompted me to suggest starting this group (and leads me to suspect (5)). It is my impression that there may be critical mass to finally reach a concensus on an SDF convention. Although UniPOPS contains a FITS reader and writer based on the '89 agreement, there are a number of unresolved issues that need to be decided before I am comfortable calling this a standard. Harvey Liszt has written a draft document titled "A FITS Binary Table Convention for Interchange of Single Dish Data in Radio Astronomy". This convention is based on the original `89 agreement, our experience within UniPOPS, and changes to the FITS binary tables format since the `89 meeting. This paper is available as a latex document (sdfits.latex) as well as a postscript document (sdfits.ps or sdfits.ps.gz) via anonymous ftp from fits.cv.nrao.edu (in /fits/documents/drafts/dishfits). There may be similar documents at other institutions based on their experience with SDF after the `89 agreement. I can easily place them into this archive. I hope it's clear at this point that this is simply a proposed convention for the use of binary tables to hold single dish data. No new FITS is involved. It involves standard column names with standard definitions and a convention for describing a data array. In my next note, I'll outline the issues that I think need to be resolved before anyone adopts this convention. I'm hoping that this exploder and adass newsgroup can be used to work through these issues to reach a convention that will be widely used. Cheers, Bob Garwood bgarwood@nrao.edu -- From dishfits-request Thu Jan 26 16:02:02 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["7616" "" "26" "January" "1995" "21:01:48" "GMT" "Bob Garwood" "bgarwood@sngldsh.cv" "" "172" "SDF unresolved issues" "^From:" nil nil "1" "1995012621:01:48" "SDF unresolved issues" (number " " mark " Bob Garwood Jan 26 172/7616 " thread-indent "\"SDF unresolved issues\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.7) id AA27936; Thu, 26 Jan 95 16:02:02 EST Return-Path: Message-Id: Organization: nrao Path: solitaire.cv.nrao.edu!news Newsgroups: adass.fits.dishfits From: bgarwood@sngldsh.cv (Bob Garwood) Sender: dishfits-request@fits.cv.nrao.edu To: dishfits@fits.cv.nrao.edu Subject: SDF unresolved issues Date: 26 Jan 1995 21:01:48 GMT This is my second note to the "dishfits" group. My first gave some very brief background and pointed everyone to a draft document: "A FITS Binary Table Convention for Interchange of Single Dish Data in Radio Astronomy". To repeat, for those that missed the original note, this document is available via anonymous ftp from: host: fits.cv.nrao.edu location: /fits/documents/drafts/dishfits files: sdfits.latex latex version sdfits.ps postscript version sdfits.ps.gz compressed (using gzip) version of sdfits.ps This note discussion what I see as the remaining unresolved issues. You will probably want to read the draft document before digesting the rest of this note. This note and the draft document are intended to be starting points for a discussion on the single dish FITS convention. The following issues need to be discussed: (1) TDIMnnn convention versus MAXIS convention for describing multi-dimensional axes in FITS binary tables. The TDIMnnn convention is the only convention explicitly mentioned in the document describing the FITS binary tables standard. The MAXIS convention was the convention adopted at the `89 meeting in Green Bank. TDIMnnn is clearly more compact when each data array in a table has the same shape. However, by using the MAXIS convention, one could place some or all of these values as columns, thereby allowing for data arrays with very different shapes to be stored in the same table (assuming the table was sized appropriately to hold the largest array). A FITS table header fragment just to make this clear: Here's the pure TDIMnnn convention for the Data column: TFORM49 = '512E ' TTYPE49 = 'DATA ' TDIM49 = '(512,1,1,1,1)' TMATX49 = T Using the MAXIS convention, this might be written as: MAXIS = 5 TFORM1 = '1I ' TTYPE1 = 'MAXIS1 ' ... MAXIS2 = 1 MAXIS3 = 1 MAXIS4 = 1 MAXIS5 = 1 If MAXIS1 = 512 throughout, then this would be exactly equivalent to the TDIM convention above. However, if MAXIS1 really does vary from column to column, then this may not be equivalent. One could still use the TDIM convention and simply pad with blanks, but I worry that this looses information (specifically, the number of channels that were actually present in the original data - perhaps this is not a fundamental loss, but it does worry me). One might also choose to do both TDIM and MAXISnnn, which would be fine in this example, assuming that the any used portion of the data vector was blank filled (this is what the unipops writer currently does). However, in order to use both safely, the data axes must be degenerate on all but the first axis. If the SDF convention is such that we require the data axes to be degenerate on all but the first axis, then there's probably little use arguing over this point. But I think thats an unnecessary limitation. Also, I'm not sure it's wise to use two conventions, even though they are compatible in most cases here - it makes readers more complicated. (2) Variable length arrays versus uniform tables. The use of the PCOUNT keyword in binary tables to specify a "heap" that can be used to place variable length arrays in a table is described in an appendix to the FITS binary table standard. It is not a part of that standard and the text in the standard recommends against it's use whenever possible. I agree with that and we should say so in the SDF document. SDF writers should group data of similar sizes in the same table so as to waste as little space as possible. Do we want to make this stronger than a simple recommendation? (3) What to do about continuum data? There are certain observing modes (e.g pointing scans) where it is impossible to identify a single axis from the standard types (TIME, FREQUENCY, SKY-POSITION, etc) that the data can be described by. Clearly multiple axes are needed to describe the data - but then they might not be regular. I've felt for a while that it would be useful to simply have a unit-less axis that is simple "Channel Number". This wasn't part of the original list of axes produced at the 1988 meeting. Should it be? Is this simply equivalent to leaving off any "CTYPEn" information for that axis? Would that be acceptable? (4) The SDF paper and the original draft from the `89 meeting clearly are concerned solely with 1-dimensional data and any additional axes are degenerate. Do we allow for multiple non-degenerate axes in the SDF convention? (5) CORE keywords: Two keywords, FREQRES, and BANDWIDT, have been promoted to the CORE keywords in this paper. Is that appropriate? CORE keywords are defined to be those REQUIRED in EVERY SDF compliant table. Is this list in this paper sufficient? Are there keywords that should not be required for EVERY SDF table that we should move into the list of SHARED keywords. (6) In the process of adding the full example, I realized that one SHARED keyword was clearly missing : RESTFREQ, the rest frequency associated with the data. Are there other SHARED keywords that we should introduce now? Once this SDF paper stabilizes is that it for the list of SHARED keywords? At the very least I think we should have some place (probably the FITS archive here) where people can register their site-specific keywords and definitions. We should then encourage people writing SDF writers to frequently look at that list so that at least we can avoid wildly different definitions for the same or similar keywords. Realistically, though, this will likely be rather anarchic. Other keyword changes I made or that should be pointed out: HOURLST - changed to LST HOURLST was the LST in (hours). Frank Ghigo used LST when he wrote the unipops SDF writer. LST is the lst in seconds. Since (seconds) are generally preferred to hours when writing time in a FITS file, I think this is a good change, so I propagated it back into the SDF document. MOLECULE and TRANSITI were originally listed as CORE in the first draft, it should be pointed out that these have been moved to SHARED, for good reasons I think - we can't require that all writers write these keywords. The UniPOPS writer uses: "PROJECT" instead of "PROJID" : PROJECT might be clearer in meaning then PROJID, but PROJID was the identified name at the `89 meeting. "BEAMWIDT" to indicate the full width at half max for a circular beam (this would be replaced by BMAJ, BMIN, and BPA in the standard - is it useful to also have BEAMWIDT? or is that just added confusion with little gain - what if we adopted the rule that if only BMAJ is present, it is assumed to be circular?). "TOUTSIDE" versus "TAMBIENT". I can't see any reason not to go with the name identified at the `88 meeting (TAMBIENT). "VCORR" versus "RVSYS". This is the radial velocity difference between the velocity reference system and the telescope (i.e. the motion of the telescope relative to the velocity reference system). Frank preferred VCORR for velocity correction. It might be a slightly clearer name than RVSYS which might be misinterpreted as a radial velocity of the system being observed (i.e. a systemic velocity) or some such. Finally, there is the general issue of definitions. The draft is rather sparse in that area at this point. These need to be as unambiguous as possible or the convention becomes rather meaningless. Which keywords are currently in need of more complete definitions? I think thats about all I can come up with now. Are there any other issues that need to be discussed? Cheers, Bob Garwood bgarwood@nrao.edu -- From dishfits-request Tue Jan 31 13:32:59 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3227" "Tue" "31" "January" "1995" "13:32:47" "+0500" "Bob Payne" "rpayne@sadira.gb.nrao.edu" "<9501311832.AA05338@vega.gb.nrao>" "75" "GBT use of FITS for single dish data" "^From:" nil nil "1" "1995013108:32:47" "GBT use of FITS for single dish data" (number " " mark " Bob Payne Jan 31 75/3227 " thread-indent "\"GBT use of FITS for single dish data\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.7) id AA19191; Tue, 31 Jan 95 13:32:59 EST Return-Path: Message-Id: <9501311832.AA05338@vega.gb.nrao> Content-Length: 3226 From: rpayne@sadira.gb.nrao.edu (Bob Payne) Sender: dishfits-request@fits.cv.nrao.edu To: dishfits@fits.cv.nrao.edu Subject: GBT use of FITS for single dish data Date: Tue, 31 Jan 1995 13:32:47 +0500 The Green Bank Telescope will produce lots of FITS binary tables. For the design of those tables we have been using the following documents: NOST FITS definition: ftp://fits.cv.nrao.edu/fits/standards/fits_standard.ps Draft Units documents: ftp://fits.cv.nrao.edu/fits/documents/drafts/ogip_93_001.ps or file://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/ofwg_recomm.html/ogip_93_001.html Preliminary Table Coordinates proposal ftp://legacy.gsfc.nasa.gov/fits_info/ofwg_recomm/coord_keywords.ps General comments: The Harvy Liszt document as a description of what was decided in Green Bank in 1989 and implemented in the UniPops FITS routines is a very useful document. It may even be a useful convention for transporting calibrated single disk line data. However viewed as a proposal for how all single dish data should be stored in FITS binary tables it invites some comments. I do not believe this proposal is adequate for uncalibrated single dish data. In order to describe the data from the Spectral Processor backend we need three tables. For each scan there may be several receivers and many phases. In addition to the definition of the data matrix itself we need tables to describe the receivers and the phases. A single scan record has a one to many relationship with receivers and with phases. In general a one to many relationship requires two tables. For calibrated data the phase and receiver dimensionality may disappear and so the additional table may have been reduced to standard coordinates described by the FITS single dish document. For data coming from the GBT backends multiple FITS tables will be needed. Units: I suggest that the FITS single dish definition adopt the conventions for units proposed in the draft memo available at "ftp://fits.cv.nrao.edu/fits/documents/drafts/ogip_93_001.ps". If that proposal is not acceptable I suggest that an alternate definition similar to the OFWG memo be provided. I note that in the example seconds is sometimes "SECONDS" and also "SEC". The IAU convention would be a lower case "s". Coordinates: The MAXIS convention is limited to describing one data matrix shape per row. If more than one data matrix with different dimensionality is needed another convention would be required. If the proposal is for all types of single dish data including uncalibrated scans with many receivers and many phases I suggest the more general conventions outlined in the OFWG recommendation for table coordinate keywords "ftp://legacy.gsfc.nasa.gov/fits_info/ofwg_recomm/coord_keywords.ps" be adopted in addition to the MAXIS convention. My own view is that for future single dish data transport the MAXIS convention should be deprecated in favor of the conventions outlined in the OFWG recommendation for coordinate keywords. To be generally useful for Single dish data the FITS format must allow for multidimensional arrays. For the GBT spectral processor these are usually (frequency,time,receiver) or (frequency,phase,receiver). The FITS binary table proposal describes a variable length record convention using a pointer. The GBT will certainly make use of that convention if needed. So far we have been to do everything with the standard TDIM convention. From dishfits-request Tue Jan 31 14:16:04 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3340" "Tue" "31" "January" "1995" "14:16:00" "+0500" "Bob Garwood" "bgarwood@nrao.edu" "<9501311916.AA07495@sngldsh.cv.nrao.edu>" "68" "Re: GBT use of FITS for single dish data" "^From:" nil nil "1" "1995013109:16:00" "GBT use of FITS for single dish data" (number " " mark " Bob Garwood Jan 31 68/3340 " thread-indent "\"Re: GBT use of FITS for single dish data\"\n") nil] nil) Received: by fits.cv.nrao.edu (4.1/DDN-DLB/1.7) id AA19418; Tue, 31 Jan 95 14:16:04 EST Return-Path: Message-Id: <9501311916.AA07495@sngldsh.cv.nrao.edu> X-Sun-Charset: US-ASCII Content-Length: 3339 From: bgarwood@NRAO.EDU (Bob Garwood) Sender: dishfits-request@fits.cv.nrao.edu To: dishfits@fits.cv.nrao.edu Subject: Re: GBT use of FITS for single dish data Date: Tue, 31 Jan 1995 14:16:00 +0500 Thanks for getting this discussion under way Bob. I agree with much of what you wrote. I would like to point out that while it may not be totally clear from the Liszt document, it does not preclude the use of multiple tables. There are several reasons why multiple tables may be necessary: (1) To group the data so that similarly sized matrices appear in the same table so as to waste as little space as possible. (2) For ancilliary information (who knows what) With that in mind, I would argue that uncalibrated single dish data is likely to be extremely telescope dependent and it's not at all surprising that additional tables may be needed. This proposal attempts to deal with general, non-telescope dependant single dish data. If the uncalibrated data can be described in terms of this convention, then you should do so but there will likely be many cases where that isn't true. I fully agree that everyone should adopt the conventions for units outlined in the draft that you mentioned. The examples in the document need to be cleaned up (in addition to SECONDS vers SEC, the text says velocites are kn km/s while cleary m/s should be used - and some of the number are clearly in m/s while others are in km/s). I would prefer if the single dish convention idenfied by EXTNAME = 'SINGLE DISH' adopt one and only one matrix convention. I haven't looked in detail at the OFWG recommendation, so I can't comment at that, but I wouldn't be at all surprised if its cleaner that what is outlined in the draft. While I'm also currently leaning in the direction of using the TDIM convention only, I'm willing to listen to other voices on this. At any rate, as I said at the start of this paragraph. I'ld prefer if we adopt a single matrix description convention and not two. Note also that Unipops has EXTNAME = "UNIPOPS SNGLE DISH" so that this convention need not encompass those files [which, for the other readers of this list/newsgroup, uses the MAXIS convention with lip service to the TDIM convention - somewhat confusing to say the least (although unipops will obviously always need to provide a reader for that type - bu thats our problem and I don't think it should influence the SINGLE DISH convention). I also have long suspected that we need to allow for multi dimensional (non-denegerate) arrays. However, the FITS binary table standard recommends agains using the variable length record convention. The question I asked in my second introductory note to this group was whether the single dish convention should simply echo that recommendation (but allow writers to use that if they choose) or to make it stronger and forbid their use. It seems to me that one could avoid using them in most cases by dividing up a data stream into several tables, each of an appopriate size so as to waste as little space for the data that are written to them. For on-line systems, this may be too difficult, but again, perhaps that is too site-specific. I'm probably leaning toward simply echoing the recommendation of the FITS binary table standard. Some time ago ( few weeks to a month or two) I noticed a message go by in sci.astro.fits about a proposal for a hierarchical table convention. Although I thought I saved it, I can't seem to find it. We might want to look at that proposal. Cheers, Bob Garwood From dishfits-request Wed Feb 1 12:31:38 1995 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["1648" "" "1" "February" "1995" "17:31:21" "GMT" "Bob Garwood" "bgarwood@sngldsh.cv" "" "37" "Re: GBT use of FITS for single dish data" "^From:" nil nil "2" "1995020117:31:21" "GBT use of FITS for single dish data" (number " " mark " Bob Garwood Feb 1 37/1648 " thread-indent "\"Re: GBT use of FITS for single dish data\"\n") "<9501311916.AA07495@sngldsh.cv.nrao.edu>"] nil) Received: by fits.cv.nrao.edu (4.1/DDN-CV/1.8) id AA22713; Wed, 1 Feb 95 12:31:38 EST Return-Path: Message-Id: Organization: nrao Path: solitaire.cv.nrao.edu!news References: <9501311916.AA07495@sngldsh.cv.nrao.edu> Newsgroups: adass.fits.dishfits From: bgarwood@sngldsh.cv (Bob Garwood) Sender: dishfits-request@fits.cv.nrao.edu To: dishfits@fits.cv.nrao.edu Subject: Re: GBT use of FITS for single dish data Date: 01 Feb 1995 17:31:21 GMT Just a quick follow-up to my last note. I've located (thanks Brian) a copy of the Hierarchical Grouping Convention for FITS proposal (this is a proposal on how to indicate groups of FITS tables). The authors of that proposal are Donald G. Jennings, William D. Pence, Michael Folk, and Barry M. Schlesinger. The posting of the proposal on sci.astro.fits was made by Don Jennings (jennings@tcumsh.gsfc.nasa.gov). You can probably request a copy from those folks (I'ld rather not post someone else's proposal). This proposal may or may not be relevant to this group. Also, Phil Jewell has suggested via e-mail that continuum data may be a prime example where variable length arrays are extremely useful. In his own words (I hope you don't mind Phil): "One annoyance concerns writing continuum data of varying size. At the 12 m, in a given data file, you may have scans with as few as 50 data points or as many as several thousand, even 10s of thousand. If you have to declare the size of your binary table to be able to accomodate the the largest scan, and be fixed in size for all the other smaller scans, this is pretty wasteful of space. Variable sized tables would help this problem." Unlike spectral line data, which is likely to come in a few similarly sized chunks, continuum data can come in virtually any length. So it seems that this is probably a good example of the need for variable length arrays. My inclination is that the SD-FITS standard echo the recommendation against variable length arrays from the FITS binary table standard but recognize that there are situations where it will be used. Cheers, Bob --