Subject: Single-dish FITS

From: "GUILLOTE@FRGAG51" <[email-masked]>
Date: Fri, 13 Oct 89 19:56:06 EDT

Date sent:  13-OCT-1989 13:52:50.84
To:   DISHFITS@NRAO

                Single-Dish FITS Format
 
        Stephane Guilloteau (1) and Thierry Forveille (2)
 
(1) Institut de Radio Astronomie Millimetrique (IRAM)
    300 Rue de la Piscine
        F-38406 Saint Martin d'Here     FRANCE
E-Mail  "[email-masked]"
 
(2) Groupe d'Astrophysique de Grenoble          (GAG)
    Observatoire de Grenoble
        BP 53 X
        F-38041 Grenoble Cedex          FRANCE
E-Mail  "[email-masked]"

        Dear collegues,
 
In the previous mails delivered through the DISHFITS exploder,
the goal of using FITS for single-dish data was not clearly exposed.
We present here an (possibly obvious, and certainly not exhaustive)
analysis of the basic needs and goals, leading to a proposal.
 
FITS is designed for "transport" of images or other data. For
single-dish data, we may consider several cases of "transport"
 
0) Transport between the same analysis program, running on
   identical computers, on different sites. FITS is not required
   in this case
1) Transport between the same analysis program, running on
   different computers. FITS may be required, since the binary
   data format can be different on the two computers. Using
   FITS instead of dedicated conversion programs avoids the need
   of dedicated programs on each type of computer
2) Transport between different analysis programs, probably running
   on different computers.
3) As a subset of 2), possible transport between dedicated single-dish
   analysis programs and "general" image processing systems (AIPS or
   others).
4) Archiving. FITS may be desirable in this case, as it guarantees
   the readability on any computer later on.
 
Each case impose some constraint on the design of a single-dish
(or image) FITS format.
 
Case 1) and 4) require that ALL the information be written on FITS
tape. This can be handled using dedicated keywords, or, as done for
AIPS, substructures in the COMMENT and HISTORY cards. Whatever the
choice of implementation, keywords are required matching EXACTLY the
data format, with a simple provision for future extensions.
 
IRAM and other observatories are currently using the CLASS program for
single-dish data analysis. The data structure for this program is
segmented in "Sections" describing some aspects of the data. The
currently used sections is described in Appendix in this MAIL.
 
Case 2), considered here as exchange between two single-dish data
analysis programs, requires some agreement upon a reasonable subset of
keywords in order to preserve most (if not all) information in the
transport. Some loss of information seems unavoidable, since not all
analysis programs have a one to one correspondence in header
parameters.
 
Case 3) is even more tricky. It is likely that a lot of information
will be lost in this case. However, a minimal requirement should be
that the data can be correctly transferred. Following the original
FITS rule, this would imply putting the data in the standard data
area, NOT in a table extension. The minimal subset of keywords to be
defined would then be NAXIS, NAXISi and BITPIX. However, most image
processing are (or should be) able to process coordinates properly,
including frequency information, and it would be highly desirable to
transfer in the most general way this information too. Looking a
little bit closer to what is a single-dish data set, we may consider
two cases :
        - Spectra
        - Continuum drifts
Spectra can be considered as 1-dimensional subsets of 3-D data cubes.
AIPS-style FITS headers could be readily used to described completely
REDUCED single-dish spectra. As an example, consider the following
FITS header, which has been produced by the CLASS to FITS conversion
program :
----------------------------------------------------------------------
 
SIMPLE  =                    T         /
BITPIX  =                   16         /
NAXIS   =                    4         /
NAXIS1  =                  512         /
NAXIS2  =                    1         /
NAXIS3  =                    1         /
NAXIS4  =                    1         /
BLANK   =                32767         / Blanking value
BSCALE  =  0.1595546564204E-05         /
BZERO   =  0.4077937081456E-01         /
DATAMIN = -0.1150350086391E-01         /
DATAMAX =  0.9305904805660E-01         /
BLOCKED =                    T         /
BUNIT   = 'K       '                   /
CTYPE1  = 'FREQ    '                   /
CRVAL1  =  0.0000000000000E+00         / Offset frequency
CDELT1  =  0.1220703125000E+05         / Frequency resolution
CRPIX1  =  0.2565000000000E+03         /
CTYPE2  = 'RA---GLS'                   /
EQUINOX =  0.1950000000000E+04         /
CRVAL2  =  0.5150368630886E+02         /
CDELT2  =  0.8333333046443E-01         /
CRPIX2  =  0.0000000000000E+00         /
CTYPE3  = 'DEC--GLS'                   /
CRVAL3  =  0.3108135491610E+02         /
CDELT3  =  0.8333333046443E-01         /
CRPIX3  =  0.0000000000000E+00         /
CTYPE4  = 'STOKES  '                   /
CRVAL4  =      1.0000000000000         /
CDELT4  =      0.0000000000000         /
CRPIX4  =      0.0000000000000         /
TELESCOP= '100-M       '               /
OBJECT  = 'NGC1333     '               /
LINE    = 'NH3(1,1)    '               / Line name
RESTFREQ=  0.2369449499989E+11         / Rest frequency
VLSR    =  0.6500000000000E+04         / Velocity of reference channel
ORIGIN  = 'CLASS-Grenoble  '           /
DATE    = '13/10/89'                   / Date written
DATE-OBS= ' 1/ 9/84'                   / Date observed
DATE-RED= '27/ 6/89'                   / Date reduced
END
----------------------------------------------------------------------
Note that CRVAL2 and CRVAL3 are coordinates at the point of tangency,
as should be, and CDELT2 CDELT3 represent here the offsets of the
observed point with respect to this reference direction. Keywords
CD00i00i may be used instead. The frequency axis is defined as an
offset to a rest frequency given in keyword RESTFREQ, and the
corresponding source velocity is given in keyword VLSR. (It may be
better to specify the frequency axis as effective observing frequency,
and use a keyword VELO-LSR for the source velocity). This header is
very close to a standard AIPS FITS header produced for a 3-D VLM cube
for example, and no "vital" information has been lost if the data is
already reduced.
 
We are not expert in "image" processing, but presumably such a FITS
header could be understood by any FITS reading program without major
loss of information (the only two non standard keywords are RESTFREQ
and VLSR).
 
Continuum drifts are handled in a similar way: the frequency axis has
dimension 1, and one sky coordinate axis has dimension equal to the
number of data points. It may be interesting to define  a very special
"projection code" for drifts in horizontal coordinates, which are
frequently used to check the telescope pointing, e.g. something like
-HOR.
 
Turning back to points 1) and 4), which imply in fact essentially the
same constraints, we believe that a hierarchical structure as
described by Bob Hanisch essentially fulfills all the requirements. As
an example, here is a (quasi) FITS header part which corresponds to
the data structure used in CLASS (See Appendix). Reference to notes
are numbered (*i). We did not bother editing a real FITS header, but
only the keywords are mentionned.

KHBEGIN = 'CLASS'                       / (*1)
VERSION = 'SEP-1989'                    / Date of version
KHBEGIN = 'POINTER'                     / (*2)
GENERAL = 20                            /
POSITION= 11                            /
SPECTRO = 15                            / Spectroscopic data
FSWITCH = 5                             / for NPHASE = 1
DRIFT   = 0                             / Not present
BEAM    = 0
CALIBRAT= 19                            / May be shorter
SKYDIP  = 0
GAUSS   = 9                             / for NLINE = 1
HFS     = 0
SHELL   = 0
CONTINUU= 0
HISTORY = 9                             / Sequence = 4
PLOT    = 4
BASE    = 8                             / For 2 windows
XCOORD  = 0                             / (*5)
KHEND
COMMENT * OBS.GENERAL : General parameters, always present
KHBEGIN ='GENERAL'      ! (mgen=9,mgen2=11)
NUMBER  =               ! rnum      ! Observation number
VERSION =               ! rver      ! Version number
TELESCOP=               ! rteles(3) ! Telescope name
DATE_OBS=               ! rdobs     ! Date of observation
DATE_RED=               ! rdred     ! Date of reduction
SYSTEM  =               ! rtypec    ! Type of coordinates
KIND    =               ! rkind     ! Type of data
QUALITY =               ! rqual     ! Quality of data
SCAN    =               ! rscan     ! Scan number
UT_TIME =               ! rut       ! UT of observation
LST_TIME=               ! rst       ! LST of observation
AZIMUTH =               ! raz       ! Azimuth
ELEVATIO=               ! rel       ! Elevation
TAU     =               ! rtau      ! Opacity
TSYS    =               ! rtsys     ! System temperature
INTEGRAT=               ! rtime     ! Integration time
KHEND
COMMENT * OBS.POSITION : Position information.
KHBEGIN ='POSITION'     ! (mpos=11)
SOURCE  =               ! rsourc(3) ! Source name
EPOCH   =               ! repoch    ! Epoch of coordinates
LAMBDA  =               ! rlam      ! Lambda
BETA    =               ! rbet      ! Beta
LAMBDA_O=               ! rlamof    ! Offset in Lambda
BETA_OFF=               ! rbetof    ! Offset in Beta
PROJECTI=               ! rproj     ! Projection system
KHEND
COMMENT * OBS.SPECTRO : Spectroscopic information (for spectra)
KHBEGIN ='SPECTRO'      ! (mspec=15)
LINE    =               ! rline(3)  ! Line name
REST    =               ! rrestf    ! Rest frequency
NCHAN   =               ! rnchan    ! Number of channels
REFERENC=               ! rrchan    ! Reference channel
FRES    =               ! rfres     ! Frequency resolution
FOFF    =               ! rfoff     ! Frequency offset
VRES    =               ! rvres     ! Velocity resolution
VOFF    =               ! rvoff     ! Velocity at reference channel
BAD     =               ! rbad      ! Blanking value
IMAGE   =               ! rimage    ! Image frequency
VELOCITY=               ! rvtype    ! Type of velocity
KHEND
COMMENT * OBS.BASE : Baseline information (for spectra of drifts)
KHBEGIN ='BASE'         ! (mwind=20,mbase=4+2*mwind)
DEGREE  =               ! rdeg      ! Degree of last baseline
SIGMA   =               ! rsigfi    ! Sigma
AREA    =               ! raire     ! Area under windows
NWINDOW =               ! rnwind    ! Number of line windows
WIND1(NWINDOW)          ! rw1(mwind)! Lower limits of windows (*3)
WIND2(NWINDOW)          ! rw2(mwind)! Upper limits of windows
KHEND
COMMENT * OBS.HISTORY : Scan numbers of initial observations
KHBEGIN ='HISTORY'      ! (mseq=100,morig=2*mseq+1)
SEQUENCE=               ! rnseq     ! Number of sequences
START(SEQUENCE)         ! rstart(mseq) ! Start can number of seq. (*4)
REND(SEQUENCE)          ! rend(mseq)   ! End scan number of seq.
KHEND
COMMENT * OBS.PLOT : Default plotting limits.
KHBEGIN = 'PLOT'                ! (mplot=4)
YMIN    =               ! ramin     ! Min Y value plotted
YMAX    =               ! ramax     ! Max Y value plotted
XMIN    =               ! rvmin     ! Min X value plotted
XMAX    =               ! rvmax     ! Max X value plotted
KHEND
COMMENT * OBS.CALIBRATION : Calibration parameters
KHBEGIN = 'CALIBRATION' ! (mcalib=19)
BEAM_EFF=               ! rbeeff    ! Beam efficiency
FORW_EFF=               ! rfoeff    ! Forward efficiency
GAIN_IM =               ! rgaini    ! Image/Signal gain ratio
H2OMM   =               ! rh2omm    ! MM of water vapor
PAMB    =               ! rpamb     ! Ambient pressure (hPa)
TAMB    =               ! rtamb     ! Ambient temperature (K)
TATMSIG =               ! rtatms    ! Atmosphere temp. signal band
TCHOP   =               ! rtchop    ! Chopper temperature
TCOLD   =               ! rtcold    ! Cold load temperature
TAUSIG  =               ! rtaus     ! Opacity signal band
TAUIMA  =               ! rtaui     ! Opacity image band
TATMIMA =               ! rtatmi    ! Atmosphere temp. image band
TREC    =               ! rtrec     ! Receiver temperature
MODE    =               ! rcmode    ! Calibration mode
FACTOR  =               ! ratfac    ! Applied calibration factor
ALTITUDE=               ! ralti     ! Site elevation
COUNTS(3)               ! rcount(3) ! Power of Atm., Chopp., Cold
KHEND
COMMENT * OBS.GAUSS : Gauss fit results (for spectra or drifts)
KHBEGIN = 'GAUSS'       ! (MXGAUS=5,mfit=3+6*MXGAUS)
NLINE   =               ! rnline    ! Number of components
SIGMA_BA=               ! rsigba    ! Sigma on base
SIGMA_RA=               ! rsigra    ! Sigma on line
FIT(3*NLINE)            ! rnfit(3*MXGAUS) ! Fit results
ERR(3*NLINE)            ! rnerr(3*MXGAUS) ! Errors
KHEND
KHEND   = 'CLASS'                       / End CLASS hierarchy
----------------------------------------------------------------------
 
(*1) Define a CLASS hierarchy
 
(*2) This structure is not required since the parameters can be derived
from a sequential reading of the following ones.
 
(*3) Here appears a rather general problem : the definition of arrays
into FITS. Common practice has been to use an index as in NAXISi for
example. But this is limited to small arrays in practice (size < 10
probably). In the list of original scan numbers (*4), the size may
be larger. This problem is fairly general and here is an opportunity
to address it. A possibility would be to use a single (non-indexed)
keyword. If the count has been previously defined, this solution is
unambigous: auto increment should simply be used by the reading
program. The two following examples would be valid, and correspond
to the following list of original scans added to produced the current
one : 100 to 110, 112 to 120, 345 to 360, 363 and 364, 400.
 
KHBEGIN ='HISTORY'
SEQUENCE= 5
START   = 100
REND    = 110
START   = 112
REND    = 120
START   = 345
REND    = 360
START   = 363
REND    = 364
START   = 400
REND    = 400
KHEND
 
KHBEGIN ='HISTORY'
SEQUENCE= 5
START   = 100
START   = 112
START   = 345
START   = 363
START   = 400
REND    = 110
REND    = 120
REND    = 360
REND    = 364
REND    = 400
KHEND
 
However this solution is very space consuming for long arrays.
Should table-like data be used for those array keywords? If so,
how could it be logically placed if hierarchies are implemented
as suggested by Bob Hanisch ? Could we use something more compact
such as
 
KHBEGIN ='HISTORY'
SEQUENCE= 5
START   = 100, 112, 345, 363, 400
REND    = 110, 120, 360, 364, 400
SEQUENCE= 1
START   = 500
REND    = 510
KHEND
 
This is non standard FITS in terms of alignment of formatted variables,
but can be easily read on any computer using a list directed I/O
Fortran format. The number of values in each line is defined by
keyword SEQUENCE here, so that the total number must be computed
by adding all values of the SEQUENCE keyword (note that the name
SEQUENCE is specific to the example. Other names would apply to other
cases).
 
(*5) XCOORD is used in CLASS for data (spectra or drifts) which are
not regularly sampled. It has been used for example to store in CLASS
format the IRAS LRS survey. The corresponding section contains
a unit for the array coordinates (integer code), followed by the
array of coordinates of the samples (here "coordinates" may be
frequency of course). This problem of irregularly sampled
data may be important in single-dish data as shown by the IRAS LRS
example. A logical solution to handle that in FITS format is the use
of standard extension tables.

In so far, we have not discussed the fate of multi-backend and/or
multi-beam observations.
 
For multi-backend, the use of AIPS-style FITS header seems to imply to
separate each backend data set in a different FITS file. An a priori
alternative would be to declare the frequency axis as randomly
sampled, but we then turn into several difficulties:
1) for reduced data, considering regularly sampled data as random ones
is obviously a lack of simplicity, and probably most processing systems
are not even able to do so (3_D VLM data cubes in AIPS with random
velociy axis?)
2) for raw data, it is likely that the calibration parameters depend
upon the backend. A specific structure would be required for
each backend.
A different FITS file for each backend is much simpler. The only disadvantage
is the loss of storage space, but the cost (and volume) of storage is
decreasing every day.
 
For multi-beam, the problem may be different, because the relative beam
positions are intrinsically random parameters, while the calibration
parameters are mostly identical for all beams. A suggestion would
be the use of GROUP data structure like in UVFITS. A few parameters
must be precised for each beam however (beam efficiency and beam sizes,
and possibly a scaling factor representing the average gain of the
backend part used for this beam).
 
Using GROUP data structure may also be possible for reduced (calibrated)
data, allowing to store a complete "random" map (regularly sampled maps
should use the normal axis coordinates). For raw data, this probably does
not make sense, as many calibration parameters will be valid only for
a few observations.

----------------------------------------------------------------------
 
In summary, following those guidelines, our proposal is (in priority order)
 
1) Always put the data in the FITS data area, NOT in an extension.
2) Put all important informations in a "standard" FITS header,
   based on the one used in AIPS for example. This "standard" header
   must be general enough to be understood by ALL FITS reading
   programs.
3) Adopt the Bob Hanisch proposal for hierarchy implementation and
   add a list of hierarchic keywords to describe completely the
   other informations. For simplicity reasons, this list may
   duplicate informations already present in the "standard" header.
4) Use table extensions for the coordinates of non regularly sampled data.
5) Use GROUP data structure for multi-beam observations, and possibly
   also for complete reduced "random" maps.
6) Find a solution for "array" keywords; we only suggested possible
   alternatives.
7) If possible, agree upon names for the hierarchical keywords,
   in order to ease data exchange between different single-dish
   reduction programs. (*) This does not preclude use of specific keywords
   for each analysis program, specially for data archive.

        Comments please...
 
(*) This is the lowest priority for us, because our FITS reading program
has the capability to define equivalent names for a keyword. This capability
is easy to implement in any program, and already saved us a lot of
additional programming time.
 

----------------------------------------------------------------------
Turning to the 6 questions asked by W.R. Burns in his original
letter, our answers are :
 
1) CLASS (Continuum and Line Analysis Simple System) for single-dish
   data,
   CLIC (Continuum and Line Interferometer Calibration) for IRAM
   interferometer data, with a data format which is an extension
   of the CLASS format
   GILDAS (Grenoble Image and Line Data Analysis Software) for
   image processing.
 
   and AIPS as a reference in interferometry.
 
2) CLASS CLIC and GILDAS are developped in collaboration between
   IRAM and GAG, and the software is now used on many sites.
 
3) External support, limited to bug repairs by lack of manpower.
   Enhancement done in-house on a "urgent need" basis.
   In house software works only under VMS up to now.
 
4) Hardware : fast workstations, probably UNIX
   Software : UNIX conversion, may be X-windows, upgrade of
   image processing to handle more specifically IRAM Plateau
   de Bure data, and more homogenously 30-m and Plateau de Bure
   data.
 
5) We use AIPS, and distribute our software. Sharing code with
   some standardization would seem unpractical given our limited
   manpower (however if anybody is interested by our small code
   to get equivalent names, it can be done of course!).
 
6) Of course, single dish data could make use of other packages. This
   is precisely the goal of our proposal points 1 and 2.

PS: Stephane Guilloteau is unable to attend the meeting, and Thierry
Forveille will be the IRAM representative.


----------------------------------------------------------------------
Appendix : data structure (in VAX-VMS FORTRAN syntax) used for
single-dish data in CLASS format, with corresponding standard
FORTRAN variable names and physical meaning:
*
        STRUCTURE /OBSERVATION_DESCR/
*
* OBS.POINTER : Length of sections. If 0, section not present.
            STRUCTURE /POINTER_DESCR/ POINTER
                INTEGER GENERAL
                INTEGER POSITION
                INTEGER SPECTRO
                INTEGER FSWITCH
                INTEGER DRIFT
                INTEGER BEAM
                INTEGER CALIBRATION
                INTEGER SKYDIP
                INTEGER GAUSS
                INTEGER HFS
                INTEGER SHELL
                INTEGER CONTINUUM
                INTEGER HISTORY
                INTEGER PLOT
                INTEGER BASE
                INTEGER XCOORD
            END STRUCTURE
*
* Section -2    /CRPAR/
* OBS.GENERAL : General parameters, always present
            STRUCTURE /GENERAL_DESCR/ GENERAL   ! (mgen=9,mgen2=11)
                INTEGER NUMBER                  ! rnum      ! Observation number
                INTEGER VERSION                 ! rver      ! Version number
                CHARACTER*12 TELESCOPE          ! rteles(3) ! Telescope name
                INTEGER DATE_OBS                ! rdobs     ! Date of observatio
n
                INTEGER DATE_RED                ! rdred     ! Date of reduction
                INTEGER SYSTEM                  ! rtypec    ! Type of coordinate
s
                INTEGER KIND                    ! rkind     ! Type of data
                INTEGER QUALITY                 ! rqual     ! Quality of data
                INTEGER SCAN                    ! rscan     ! Scan number
                REAL*8  UT_TIME                 ! rut       ! UT of observation
                REAL*8  LST_TIME                ! rst       ! LST of observation
                REAL*4  AZIMUTH                 ! raz       ! Azimuth
                REAL*4  ELEVATION               ! rel       ! Elevation
                REAL*4  TAU                     ! rtau      ! Opacity
                REAL*4  TSYS                    ! rtsys     ! System temperature
                REAL*4  INTEGRATION             ! rtime     ! Integration time
            END STRUCTURE
*
* Section -3
* OBS.POSITION : Position information.
            STRUCTURE /POSITION_DESCR/ POSITION ! (mpos=11)
                CHARACTER*12 SOURCE             ! rsourc(3) ! Source name
                REAL*4  EPOCH                   ! repoch    ! Epoch of coordinat
es
                REAL*8  LAMBDA                  ! rlam      ! Lambda
                REAL*8  BETA                    ! rbet      ! Beta
                REAL*4  LAMBDA_OFF              ! rlamof    ! Offset in Lambda
                REAL*4  BETA_OFF                ! rbetof    ! Offset in Beta
                INTEGER PROJECTION              ! rproj     ! Projection system
            END STRUCTURE
*
* Section -4
* OBS.SPECTRO : Spectroscopic information (for spectra)
            STRUCTURE /SPECTRO_DESCR/ SPECTRO   ! (mspec=15)
                CHARACTER*12 LINE               ! rline(3)  ! Line name
                REAL*8  REST                    ! rrestf    ! Rest frequency
                INTEGER NCHAN                   ! rnchan    ! Number of channels
                REAL*4  REFERENCE               ! rrchan    ! Reference channels
                REAL*4  FRES                    ! rfres     ! Frequency resoluti
on
                REAL*4  FOFF                    ! rfoff     ! Frequency offset
                REAL*4  VRES                    ! rvres     ! Velocity resolutio
n
                REAL*4  VOFF                    ! rvoff     ! Velocity at refere
nce channel
                REAL*4  BAD                     ! rbad      ! Blanking value
                REAL*8  IMAGE                   ! rimage    ! Image frequency
                INTEGER VELOCITY                ! rvtype    ! Type of velocity
            END STRUCTURE
*
* Section -5
* OBS.BASE : Baseline information (for spectra of drifts)
            STRUCTURE /BASE_DESCR/ BASE         ! (mwind=20,mbase=4+2*mwind)
                INTEGER DEGREE                  ! rdeg      ! Degree of last bas
eline
                REAL*4  SIGMA                   ! rsigfi    ! Sigma
                REAL*4  AREA                    ! raire     ! Area under windows
                INTEGER NWINDOW                 ! rnwind    ! Number of line win
dows
                REAL*4  WIND1(MWIND)            ! rw1(mwind)! Lower limits of wi
ndows
                REAL*4  WIND2(MWIND)            ! rw2(mwind)! Upper limits of wi
ndows
            END STRUCTURE
*
* Section -6
* OBS.HISTORY : Scan numbers of initial observations
            STRUCTURE /HISTORY_DESCR/ HISTORY   ! (mseq=100,morig=2*mseq+1)
                INTEGER SEQUENCE                ! rnseq     ! Number of sequence
s
                INTEGER START(MSEQ)             ! rstart(mseq) ! Start can numbe
r of seq.
                INTEGER END(MSEQ)               ! rend(mseq)   ! End scan number
 of seq.
            END STRUCTURE
*
* Section -7
* OBS.PLOT : Default plotting limits.
            STRUCTURE /PLOT_DESCR/ PLOT         ! (mplot=4)
                REAL*4  YMIN                    ! ramin     ! Min Y value plotte
d
                REAL*4  YMAX                    ! ramax     ! Max Y value plotte
d
                REAL*4  XMIN                    ! rvmin     ! Min X value plotte
d
                REAL*4  XMAX                    ! rvmax     ! Max X value plotte
d
            END STRUCTURE
*
* Section -8
* OBS.FSWITCH : Frequency switching information (for spectra)
            STRUCTURE /FSWITCH_DESCR/ FSWITCH   ! (mxphas=5,mfsw=1+4*mxphas)
                INTEGER NPHASE                  ! rnphas    ! Number of phases
                REAL*8  DECALAGE(MXPHAS)        ! rdecal(mxphas) ! Frequency off
sets
                REAL*4  DUREE(MXPHAS)           ! rduree(mxphas) ! Time per phas
e
                REAL*4  POIDS(MXPHAS)           ! rpoids(mxphas) ! Weight of eac
h phase
            END STRUCTURE
*
* Section -14
* OBS.CALIBRATION : Calibration parameters
            STRUCTURE /CALIBRATION_DESCR/ CALIBRATION   ! (mcalib=19)
                REAL*4  BEAM_EFF                ! rbeeff    ! Beam efficiency
                REAL*4  FORW_EFF                ! rfoeff    ! Forward efficiency
                REAL*4  GAIN_IM                 ! rgaini    ! Image/Signal gain
ratio
                REAL*4  H2OMM                   ! rh2omm    ! MM of water vapor
                REAL*4  PAMB                    ! rpamb     ! Ambient pressure (
hPa)
                REAL*4  TAMB                    ! rtamb     ! Ambient temperatur
e (K)
                REAL*4  TATMSIG                 ! rtatms    ! Atmosphere temp. s
ignal band
                REAL*4  TCHOP                   ! rtchop    ! Chopper temperatur
e
                REAL*4  TCOLD                   ! rtcold    ! Cold load temperat
ure
                REAL*4  TAUSIG                  ! rtaus     ! Opacity signal ban
d
                REAL*4  TAUIMA                  ! rtaui     ! Opacity image band
                REAL*4  TATMIMA                 ! rtatmi    ! Atmosphere temp. i
mage band
                REAL*4  TREC                    ! rtrec     ! Receiver temperatu
re
                INTEGER MODE                    ! rcmode    ! Calibration mode
                REAL*4  FACTOR                  ! ratfac    ! Applied calibratio
n factor
                REAL*4  ALTITUDE                ! ralti     ! Site elevation
                REAL*4  COUNTS(3)               ! rcount(3) ! Power of Atm., Cho
pp., Cold
            END STRUCTURE
*
* Section -16
* OBS.SKYDIP : For Skydips observations. No associated data.
            STRUCTURE /SKYDIP_DESCR/ SKYDIP     ! (msky=10,mskydip=10+4*msky)
                CHARACTER*12 LINE               ! rsline(3) ! Line name
                REAL*8  REST                    ! rsrest    ! Rest frequency
                REAL*8  IMAGE                   ! rsimag    ! Image frequency
                INTEGER NSKY                    ! rnsky     ! Number of points o
n sky
                INTEGER NCHOP                   ! rnchop    !    -   -    -    -
 chopper
                INTEGER NCOLD                   ! rncold    !    -   -    -    -
 cold load
                REAL*4  ELEVATION(MSKY)         ! relev(msky)  ! Elevations
                REAL*4  EMISSION (MSKY)         ! remiss(msky) ! Power on sky
                REAL*4  CHOPPER  (MSKY)         ! rchopp(msky) ! Power on choppe
r
                REAL*4  COLD    (MSKY)          ! rcold(msky)  ! Power on cold l
oad
            END STRUCTURE
*
* Section -9    /CRGAUS/
* OBS.GAUSS : Gauss fit results (for spectra or drifts)
            STRUCTURE /GAUSS_DESCR/ GAUSS       ! (MXGAUS=5,mfit=3+6*MXGAUS)
                INTEGER NLINE                   ! rnline    ! Number of componen
ts
                REAL*4  SIGMA_BASE              ! rsigba    ! Sigma on base
                REAL*4  SIGMA_RAIE              ! rsigra    ! Sigma on line
                REAL*4  FIT(3*MXGAUS)           ! rnfit(3*MXGAUS) ! Fit results
                REAL*4  ERR(3*MXGAUS)           ! rnerr(3*MXGAUS) ! Errors
            END STRUCTURE
*
* Section -12   /CRSHEL/
* OBS.SHELL : "Stellar shell" profile fit results (for spectra)
            STRUCTURE /SHELL_DESCR/ SHELL       ! (mshell=43)
                INTEGER NLINE                   ! rlshel    ! Number of componen
ts
                REAL*4  SIGMA_BASE              ! rbshel    ! Sigma on base
                REAL*4  SIGMA_RAIE              ! rrshel    ! Sigma on line
                REAL*4  FIT(20)                 ! rnshel(20)! Fit results
                REAL*4  ERR(20)                 ! reshel(20)! Errors
            END STRUCTURE
*
* Section -13   /CRNH3/
* OBS.HFS : "Hyperfine Structure" profile fit results (for spectra)
*           (e.g. NH3, HCN)
            STRUCTURE /HFS_DESCR/ HFS           ! (mnh3=27)
                INTEGER NLINE                   ! rlnh3     ! Number of componen
ts
                REAL*4  SIGMA_BASE              ! rbnh3     ! Sigma on base
                REAL*4  SIGMA_RAIE              ! rrnh3     ! Sigma on line
                REAL*4  FIT(12)                 ! rnnh3(12) ! Fit results
                REAL*4  ERR(12)                 ! renh3(12) ! Errors
            END STRUCTURE
*
* Section -10   /CRCONT/
* OBS.DRIFT : Continuum drift description (for drifts)
            STRUCTURE /DRIFT_DESCR/ DRIFT       ! (mcont=16)
                REAL*8  REST                    ! rfreq     ! Rest frequency
                REAL*4  WIDTH                   ! rwidth    ! Bandwidth
                INTEGER NPOINT                  ! rnpoin    ! Number of data poi
nts
                REAL*4  REFERENCE               ! rrpoin    ! Reference point
                REAL*4  TIMOFF                  ! rtref     ! Time at reference
                REAL*4  ANGOFF                  ! raref     ! Angular offset at
ref.
                REAL*4  PA                      ! rapos     ! Position angle of
drift
                REAL*4  TIMRES                  ! rtres     ! Time resolution
                REAL*4  ANGRES                  ! rares     ! Angular resolution
                REAL*4  BAD                     ! rcbad     ! Blanking value
                INTEGER SYSTEM                  ! rctype    ! Type of offsets
                REAL*8  IMAGE                   ! rcimag    ! Image frequency
                REAL*4  COLLA                   ! rcolla    ! Collimation error
Az
                REAL*4  COLLE                   ! rcolle    ! Collimation error
El
            END STRUCTURE
*
* Section -11
* OBS.BEAM : Beam-switching parameters (for spectra or drifts)
            STRUCTURE /BEAM_DESCR/ BEAM         ! (mbeam=5)
                REAL*4  AZIMUTH                 ! rcazim    ! Azimuth of observa
tion
                REAL*4  ELEVATION               ! rcelev    ! Elevation of obser
vation
                REAL*4  THROW                   ! rspace    ! Beam spacing
                REAL*4  PA                      ! rbpos     ! Position angle of
beams
                INTEGER SYSTEM                  ! rbtype    ! System for angle
            END STRUCTURE
*
* Section -15 /CRPOINT/
* OBS.CONTINUUM : Double gaussian and baseline fit results (for drifts)
            STRUCTURE /CONT_DESCR/ CONTINUUM    ! (mfcont=19)
                INTEGER NLINE                   ! rlcont    ! Number of componen
ts
                REAL*4  SIGMA_BASE              ! rbcont    ! Sigma on base
                REAL*4  SIGMA_RAIE              ! rrcont    ! Sigma on line
                REAL*4  FIT(8)                  ! rncont(8) ! Results
                REAL*4  ERR(8)                  ! recont(8) ! Errors
            END STRUCTURE
        END STRUCTURE
*

---

From: [email-masked] (Don Wells)
Date: Mon, 16 Oct 89 09:55:54 EDT

Dear friends,

The Guilloteau and Forveille paper is a perceptive and sophisticated
discussion of FITS issues for single-dish astronomy. It is a valuable
contribution in preparation for the Green Bank workshop.

Here are some comments, corrections, differences of opinion:

1. re matrices versus tables:

Stephane and Thierry stress that data transfer from single-dish
systems to "general" IP systems should be by means of images (n-dimensional
matrices) in classical FITS form. I agree that *if* the data are an 
n-dimensional matrix then the Basic FITS format should be used. However,
I am optimistic that we will soon have effective interchange capability
for other types of data structures, particularly tables. I contend that
we must make the effort to build and demonstrate this capability in many
systems so that astronomical data interchange and archiving will no longer
be confined to matrices. I would like to see the single-dish community take
a leadership role in this effort.

2. re list-directed-READ for FITS value fields:

In March 1979 Eric Greisen and I agreed that FITS keyword value fields
would use the notation of FORTRAN list-directed READs. The list-directed
READ design allows for lists of values, and Eric and I understood what we
were proposing. My memory is that when the design went to the review panel
in April-May 1979 there were strong protests that many computer systems
were not sophisticated enough to cope with completely free-field headers,
that our design was too sophisticated and that it ran the risk of being
ignored by many groups in astronomy. We compromised. We stopped talking 
about multi-valued keywords and we even gave up the free-field concept ---
we specified that the required keywords of a FITS header must be in a rigid
format so that unsophisticated readers would have an easier job.

The multiple-value problem is fundamental. I do not have a nice, neat 
answer for it. In headers we have another problem: Eric and I decided
that all standard header lines would fit into one "card". This limits how
many values a keyword can have. I believe now that the best solutions will
use tables, with separate tuples for the values.

3. re irregularly sampled data:

The classical answer to this problem is the random-groups format.
Indeed, since 1980 the leading FITS designers have all been somewhat sad
that we did not think of random-groups until after the Basic FITS Agreement
had already been implemented in production systems. We wish that Basic FITS
had been the random-groups format, so that simple matricies would be a 
special case. In 1984 we made the Generalized Extensions Agreement have this
form.

Jim Condon of NRAO and his collaborators have made several surveys of the
northern sky with the 300-foot in a rapid scanning mode using a seven-beam
feed. The randomly sampled data were formatted as random-groups FITS.
AIPS is able to read such data (see relevant sections of Going AIPS for details)
and there are tasks which can grid the samples into maps of the sky. Indeed,
the tasks are variations on the aperture synthesis task UVMAP (the Fourier
transform step is skipped). The random samples are sorted using task UVSRT.
I.e., FROM THE POINT OF VIEW OF A PROGRAMMER, RANDOM SAMPLES OF FLUX ON THE
SKY ARE STRUCTURALLY ALMOST IDENTICAL TO THE RANDOM SAMPLES OF THE UV PLANE
ACQUIRED IN APERTURE SYNTHESIS, AND SIMILAR SOFTWARE APPROACHES ARE FEASIBLE.
Note that scanning infrared satellite data (IRAS) and high-energy photon
event data fall in this same class. Although the 300-foot surveys were
continuum data only I believe that the AIPS tasks are more general, that
they can sort and grid spectral-line surveys.

Bill Cotton's "3-D Binary Tables" design, which he devised for 
VLBA calibration, is yet another approach to the irregularly sampled data
problem. It is not as elegant mathematically, but the bit stream that it
produces is essentially *identical* to that produced by random groups (so
that there is no difference in efficiency) and he can transmit data types
that random-groups cannot handle.

4. re hierarchical keyword syntax:

Bob Hanisch has raised two issues: (1) "Do we really need a hierarchical
namespace?" and (2) "What syntax should we use?". I still believe that
the FITS community should endeavour to transmit *MEANING* (semantics) as well
as mere *DATA* (syntax), and I believe that it will be necessary to organize
our name-space in order to achieve this goal reliably. However I am grateful
to Bob for having the courage to go against the common wisdom in this area,
to make us think about the issue. Regarding syntax, there are two proposals.
Either we devise rules for what I call the "push-down-stack" syntax (the
concept discussed by Hanisch and endorsed by Guilloteau and Forveille), or 
we adapt the existing "domain-name-system" rules for single keyword=value
header cards. I think that either approach can probably be made towork in 
the end, but I have more confidence in the second approach.

I have a paper of my own which has been in preparation for several weeks,
and I expect to broadcast it soon.

Regards,
Don

Donald C. Wells, Associate Scientist | NSFnet: [email-masked] [192.33.115.2]
National Radio Astronomy Observatory | SPAN:   NRAO::DWELLS    [6654::]
Edgemont Road                        | BITnet: DWELLS@NRAO
Charlottesville, VA 22903-2475 USA   | UUCP:   ...!uunet!nrao.edu!dwells
+1-804-296-0277  (38:02.2N/78:31.1W) | TWX=510-587-5482, Fax=+1-804-296-0278