NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > PlanOfRecordC32006 > ModificationRequest1C306 > ModificationRequest4C406

Changes | Index | Contents | Search | Statistics | Go

Integration of the Zpectrometer into the sdfits tool

Modification Request #4 (C04 2006)

• 1. Introduction
• 2. Background
• 3. Requirements
  • Scan
  • Frequency, polarization and sideband
  • DATA and DATA axes
  • Additional New Columns to be added by sdfits.
  • Other changes to the table structure.
  • Associated information
  • Associated files
  • Index File
• 4. Design
  • Banks, Samplers, Integrations, Phases, and related information
  • API Level Classes
    • Scan Class
    • Zpectrometer Backend Class
    • ZpectrometerScanData Class
    • Output SDFITS Structure Classes
  • Application Level Classes
    • SDFITSWriter Class
    • ZpectrometerIndex Class
• 5. Deployment Checklist
• 6. Test Plan
  • 6.1 Internal Testing
  • 6.2 Sponsor Testing
  • 6.3 Integration/Regression Tests
• Signatures
• CCC Discussion Area
• Appendix A: Structure of Zpectrometer SDFITS file

1. Introduction

This MR is to address the data reduction needs of the Zpectrometer and how best to integrate it into the data capture process at the GBT.

The Zpectrometer is an ultra-wideband spectrometer being built by the University of Maryland for use with the GBT and its Ka-band receiver. The Zpectrometer differs from most other M&C backends in that the UMd provided Zpectrometer software writes a FITS file and several associated files, instead of the M&C Zpectrometer Manager writing an instrument FITS file. The format of the Zpectrometer FITS file reflects its history as a multi-telescope instrument. The Zpectrometer FITS file borrows heavily from the SDFITS convention. As produced by the backend, though, it is not yet an SDFITS file. The Zpectrometer FITS file has many keywords and columns that cannot be filled in by the backend Manager. These values must be supplied by the data capture process which must use the other M&C FITS files, such as those for the Antenna, IF, LO, Ka, etc. In addition, the steps necessary to produce a spectrum with a calibrated, linear frequency axis (a requirement for the SDFITS convention and for use with GBTIDL and other common single dish data analysis packages) will not have been done when the Zpectrometer FITS file is written. As a consequence, the data capture development is being split into three parts as illustrated in this figure.

• Zpectrometer Data Capture Diagram:
  

The top of the figure illustrates how data capture fits into the flow of data at the GBT. The backend devices and other managers produce a set of FITS files. Those FITS files are collected and used in the data capture process to produce an SDFITS file that can be consumed by a data analysis package like GBTIDL. The tool that does this at the GBT is also called "sdfits".

In the case of the Zpectrometer (illustrated in the box at the bottom of the figure), the data capture steps are still under development. During development, they have been split into 3 steps. In the first step, the sdfits tool will take the raw FITS file produced by the Zpectrometer and use the other M&C FITS files to produce a new FITS file that includes that information and follows the SDFITS convention. This MR describes the work necessary to modify the sdfits tool so that it can do that step.

The second step involves reading the output of the sdfits tool into IDL. The work necessary to support that step is described in a separate MR.

In the third step, IDL functions and procedures are used to calibrate the frequency axis and place the resulting data and associated information into a GBTIDL spectrum data container (or arrays of data containers). Once in a GBTIDL spectrum data container, the data can be saved to disk using existing GBTIDL toolbox procedures, functions, and classes. This last step (everything described in this paragraph) will not be done by NRAO staff, although they will be available for advice and consultation.

2. Background

For more information on the Zpectrometer project, see the NRAO Zpectrometer Wiki.

The details on the creation of a M&C Manager for the Zpectrometer can be found at ModificationRequest1C306.

A list of the keywords required for the WASP data product can be found here.

The format of the Zpectrometer SDFITS file, along with a link to an example file with 1 row of data, can be found in Appendix A.

3. Requirements

This work needs to be done by October 1, 2006 (the related GBTIDL MR also needs to be completely by the same date).

The sdfits tool will consume the raw Zpectrometer FITS file (an example is attached to this MR) and produce an SDFITS-compliant FITS file that is a copy of much of the contents of the raw file. This section describes which fields need to be modified and which need to be added during that copying step and where that information will come from. In most cases, the information needed here is similar to what sdfits supplies for the other backends that it handles and in those case, the information should come from the same place using the same code. All keywords/columns found in the original, raw, Zpectrometer FITS file not explicitly mentioned here will be copied over as is by the sdfits tool into the output SDFITS file for use in GBTIDL. There is no requirement during this development stage for the online sdfits filler to process data from this backend.

Scan

Frequency, polarization and sideband

The Zpectrometer observes the entire Ka band as output by the Ka receiver. Doppler tracking during an observation (to correct for the Earth's rotation) will not be used. Instead, a fictional rest frequency of 32.6 GHz will be set during configuration along with a source velocity of 0 km/s. The doppler tracking tolerance will be large so that LO1 will be set once at the start of the scan to place that rest frequency in the middle of the band after any doppler corrections due to the earth's orbital motion.

Entries for this backend will appear in the IF FITS files. These can be used to find the center of the band as determined in the standard way using the LO1 value from the LO1 FITS file as with other backends. The work to support this will not be completed until mid October. It is expected that the IF FITS fill will contain two rows when configured to support the Zpectrometer. One will be labelled as Bank A, Port 1 and the other as Bank A, Port 2. Both rows should correspond to the same frequency (different beams/polarizations) and so it will only be necessary to examine one row associated with the Zpectrometer to work out the sky frequency associated with that scan.

The two Ka receiver outputs (each covering the entire Ka band, one from each beam/polarization) are input to the Zpectrometer which breaks the Ka band up into 4 segments, one for each of the internal Zpectrometer backends. The exact frequency axis in each backend is determined during the calibration process and is not available to the sdfits tool at this time. Instead, the sdfits tool will set CRVAL1 in all rows of a given scan to be the sky frequency corresponding as determined by the IF manager and LO1 fits file at the start of the scan. During the short period during this development project when the IF manager file is not available, the sdfits tool will assume that the sky frequency was set as expected resulting in the center frequency corresponding to a doppler tracked frequency of 32.6 GHz. It will use the available doppler tracked frame velocity (VFRAME) from the LO1 FITS file to calculate what the corresponding sky frequency was at the start of the scan. That value will be used for CRVAL1. CDELT1 will be set to 16.4 MHz. BANDWID will be set to 4.2 GHz, which is the full bandwidth of each backend. That later value is unlikely to be used during calibration in IDL. It is only provided because the SDFITS convention requires a value for BANDWID.

A polarization associated with a given row of the Zpectrometer backend FITS file can not be assigned by sdfits because of the nature of the correlations that the backend performs. No STOKES axis will be added to the data axes and the POLARIZ keyword will be arbitrarily set to RL (as opposed to LR) by the sdfits tool.

There is no image sideband associated with this backend and so related keywords will be unchanged by the sdfits tool.

DATA and DATA axes

SDFITS requires that the DATA values are at least 3-dimensional with all but the first axis having a single element. The raw Zpectrometer FITS file has a 1-dimensional DATA array and only one axis is described using CRVAL1, CRPIX1, and CDELT1. CTYPE1 is missing. In the SDFITS convention, the first required axis is frequency. The second required axis is longitude-like (RA, Galactic longitude, etc) and the third required axis is latitude-like (DEC, Galactic latitude, etc). These required axes will be added by the sdfits tool to make it's output compliant with the SDFITS convention.

Note that xx in TDIMxx (the FITS column number of the DATA column) must be determined from the FITS file and not just from one example since the location of the DATA column may move.

Note that CRPIX and CDELT are not needed for the single-element axes (1 is assumed for CRPIX if unspecified according to common FITS usage). The CRVAL2 and CRVAL3 values are determined exactly as they are for other backends that sdfits already handles.

In this table, the Value column indicates either what the value of that keyword should be or what the source of that value is in an M&C FITS file. In the later case, the value of the keyword/cell in the output FITS table is not simply a copy of the M&C value indicated in this table. The Method column indicates what method in the existing sdfits (sparrow) code is to be used to produce the true value that is assigned to that keyword. The New? column will say "Y" if this keyword is not found in the original Zpectrometer FITS file. If the value in the KW? column is "Y" then this value can be represented as a true keyword instead of a table column (it is a virtual column). Note that for the new TDIMxx keyword, "xx" is the DATA column number and "256" is used here because the Zpectrometer will always produce 256-element DATA arrays when used on the GBT. Although we expect that the data array will have 256 elements, there is no reason not to use the found value of the length of the data array in constructing the value of TDIMxx.

Additional New Columns to be added by sdfits.

These columns need to be added by sdfits. They do not appear in the raw FITS files produced by the Zpectrometer.

BANDWID is required by the SDFITS convention, MC_SCAN is added for the reasons described above, PRESSURE is an additional weather parameter available in the Antenna FITS file at the start of a scan and it is added here for consistency with the other files that sdfits can produce. TIMESTAMP is simply the common timestamp used in the name of each FITS file produced during one M&C scan. We have found that useful in data processing since the M&C system does not guarantee a unique M&C scan number.

The TRCKBEAM keyword from the header of the Antenna FITS fill will be copied as is from the Antenna FITS file. It records which beam was at the tracked position at the start of the scan. The XELOFFSET and ELOFFSET columns will come beam offset table of the Antenna FITS file. These will each be 2-element double precision columns to hold the offset for each beam associated with the Ka receiver as found in the Antenna FITS file. This information could be used in post-processing to determine where the off position was located.

There are 3 additional parameters that Astrid puts in to the GO FITS file that may be useful: PROCNAME, PROCSEQN, and PROCSIZE. The first is the name of the observing procedure, the other two are used for multi-MC_SCAN procedures (e.g. Nod, OnOff, maps). PROCSIZE indicates the total number of MC_SCAN expected from that execution of that procedure and PROCSEQN is what number this MC_SCAN is in the procedure. These can be used during data analysis to tell what the other scan is in a scan pair or whether all scans were actually observed during a mapping procedure.

These values do not change during an MC_SCAN but they may change from one MC_SCAN to the next and so they need to be columns in the output FITS file.

Other changes to the table structure.

The following columns will be removed by sdfits and replaced by single value keywords: BACKEND, SITELONG, SITELAT, and SITEELEV. This matches the behavior of sdfits with other backends. This allows more code reuse. The CUNIT1 column is also removed and replaced with TUNIT keywords for CRVAL1 and CDELT1. This is being done because it is less confusing to have a TUNIT value for the two frequency columns involved in the first axis (CRVAL1 and CDELT1). These columns are always "Hz".

The following keywords in the Zpectrometer FITS file will be converted to columns since their values can change over time: OBJECT, OBSERVER, OBSID, OBSNUM, and SCANRANGE. The last two values (OBSNUM, and SCANRANGE) for a given scan will come from that Zpectrometer FITS file, the first 3 will come from the GO FITS file as described in the next section.

The TFORM values for string columns will be changed from "xAx" to simply "xA" (e.g. 32A32 to 32A). The IDL FITS routines we use do not understand this syntax. It is a convention for representing substring arrays in a binary table. In this form, the substrings have a fixed length equal to the number after the "A". In all cases in the Zpectrometer file, that trailing number is equal to the leading number and so there is no loss of information in removing the trailing numbers.

Associated information

The keywords and columns described here already exist in the raw Zpectrometer FITS file. The sdfits tool must supply a value for each of these as it writes it's output FITS file.

Any keyword found in the original, raw, Zpectrometer FITS file not mentioned in this table or the table of removed columns and keywords is copied over without change by sdfits. This includes keywords that the Zpectrometer also can not supply anything but a default value (e.g. FOFFSET, VOFFSET, RAREF, DECREF, LREF, BREF, AZREF, ELREF, TCAL, TRX, TSYS, TAU, etc).

Associated files

There are three files who's names are recorded in the Zpectrometer backend FITS file when it is written and which are needed during the calibration process. The names of these files are stored in the SIGSFILE, CALFILE, and WASPDEFS columns of the backend FITS file. Many backend FTIS files will typically reference the same associated files. The sdfits tool will ensure that a copy of each file named in these three columns is placed in the same output directory where the product of the sdfits tool is found. A value of "undefined" means that there is no file of that type to check for that row.

Index File

The sdfits tool produces an index file to facilitate using the SDFITS file with GBTIDL. When absent or when the format of the index file changes, GBTIDL can regenerate the index file from the SDFITS file. The index file will have these fields: INDEX, FILE, EXTENSION, ROW, MC_SCAN, SCAN, BEINDEX, SOURCE, TRCKBEAM, PROJECT, OBSERVER, PROCEDURE, DIODE, AZIMUTH, ELEVATION, LONGITUDE, EXPOSURE, OBSFREQ, and TIMESTAMP. The first 4 values are required by the GBTIDL data i/o model. The rest of the values from from the data in the SDFITS file. Most of them are simply copies of the same-named column in the SDFITS file. SOURCE is a copy of the OBJECT value and LONGITUDE and LATITUDE are copies of the CRVAL2, and CRVAL3 values, respectively. These later names are chosen here because they are used in the same sense as the spectral line index columns in GBTIDL.

4. Design

The sdfits program must be modified to reduce data for this new backend. However, this backend does not need to be supported for common use for about another year, so there is no rush to get the desired modifications into the Sdfits production code. In fact, the requirements for the final sdfits reduction of Zpectrometer data are likely to change significantly in the next 6 months to a year.

With these factors in mind, the design used for this modification to the sdfits program should not take into account any long term plans, and should be considered a stop-gap measure. In particular, the long-overdue plans to refactor the internals of the sdfits program and related Sparrow code (see SdfitsRedesign05), should be put off.

To isolate the work in support of this MR, it will take place in a completely separate branch of Sparrow, so that these changes do not leak into near future SDD releases. A tag will be used to mark the trunk, then a branch will be created. This branch can always be merged back into the trunk if parts of development are desired for future releases.

Banks, Samplers, Integrations, Phases, and related information

Here's a quick overview of how the sdfits tool currently gathers information and writes it out.

For each scan being filled:

• Most associated information (nearly everything except the spectra) are gathered in ScanData. Backend classes are setup.
• In SDFITSWriter, each row of the file is written, iterating through, sequentially:
  • Bank
  • Sampler
  • Integration
  • Phase

This is necessary for other backends because the data are stored in a multi-dimensional array and the SDFITS file's DATA column is essentially one-dimensional (the extra dimension are "degenerate", having only one pixel). So, where the Spectrometer's raw lags are found in array of [lags,sampler,phase] and each row in that FITS file contains data from one integration and there may be up to 4 files, each containing data from one bank, in the Zpectrometer case, the lags are already in a one-dimensional vector and there is only one file so there is no need to iterate through anything more than the rows in teh Zpectrometer backend FITS file as they are encountered.

Still, it may be useful to understand how these terms are related to the Zpectrometer data when trying to reuse existing python code in support of this MR.

• Bank: The safest thing to do would be to probably think of the Zpectrometer as just one Bank, since this is how the IF Manager will be seeing things. As discussed elsewhere, this will be bank "A".
• Sampler: at this point in time, we have no corresponding sampler name info, however, this may be closest to the backend number (BEINDEX).
• Integration: for consistency with other uses, integration should be the same as the count of the unique times in DATE-OBS in that FITS file.
• Phase: This corresponds only to multiple DIODE states. In other words, when the DIODE is not firing, it's value is always zero, and if one integration is written per MC_SCAN then there will be four rows (one for each backend). However, if the high cal is firing, then DIODE's value will alternate between 0 (off) and 1 (or -1), and there will be 8 rows.

API Level Classes

Scan Class

The Zpectrometer must be added to the list of valid Backends.

Zpectrometer Backend Class

A new Zpectrometer backend class should be created in the same fashion as the other existing spectral line classes. These could be Zpectrometer, and ZpectrometerData, though the need for two classes could be put into question. Among the other backends, the *Data class usually contains only FQL statements, returns data in python structures. The backend class is then usually responsible for the formatting or use of those results for public methods.

In our current circumstances, the majority of the data from the Zpectrometer FITS file will simply be copied over to the product of the sdfits tool. In this case, a smaller code base in one class would probably be more appropriate, making use of a generic getValue( rowNumber, columnName ) method.

ZpectrometerScanData Class

The ScanData class is used by the SDFITSWriter class (part of the sdfits application) for gathering all the data that this writer class puts in the SDFITS file. This is a Frankenstein Monster, bloated and scarred with nested 'if' statements for determining what backend classes to use. However, a large percentage of it can be reused for the backend-dependent data (GO FITS file info, Antenna positions, etc.).

Rather then contributing to the tragedy, a short-term solution will be to inherit from this class to create the ZpectrometerScanData class. For this new class, certain new methods will need to be created, while some ScanData methods will need to be overwritten. Meanwhile, most public methods can be reused. We will now try to specify these methods and how they should be treated.

ScanData is used in the following way. An instance of the class is created, the backend is set, and then, for each scan to be filled, the setScan method is called, passing a scan object, the data mode, and a receiver object. In our case, the mode will be "raw", and the receiver object will be managing the calibration FITS file for the Ka Receiver. This method in turn, gathers most of the needed information (nearly everything except the spectra) and caches it. Then public interface methods are used to access the data that has been gathered.

The table below lists all the methods that are called by setScan in "raw" data mode that need to be overridden ZpectrometerScanData. By doing this, the setScan method can be called and the appropriate access methods used to access the desired information.

Method Name	Notes
gatherBackend	simple case of adding "Zpectrometer" name
gatherNumberOfIntegrations	we can hard-code this to return 1
gatherIntegrationDuration	if no DIODE switching, use EXPOSURE value
gatherScanStartDMJD	use DATE-OBS value, convert
gatherIntegrationDateObses	use DATE-OBS value
gatherIntegrationMidDMJDs	calculate using DATE-OBS and EXPOSURE
gatherIntegrationStateDurations	calculate using EXPOSURE values
gatherIntegrationStateExposures	since no blanking, will be same as durations

In the above calculations, proper care must be taken to use EXPOSURE correctly:

• Blanking time is negligible, so duration and exposure times can be taken to be equal
• For no DIODE-switching, EXPOSURE == integration time
• For DIODE-switching, 2*EXPOSURE == integration time
• In either case, we will store the duration (integration time) used in the DURATION column.

Although we expect there to be one integration per MC_SCAN, the values listed above should be stored as python lists of one element, so that the public access methods, which take an integration index number, can use 0 as a valid argument.

Finally, there are several methods which can be used as is, since they gather information from auxiliary FITS files (files other then the backend). However, they should be noted, since, if the auxillary file is missing, they attempt to get this data from the backend file. In other words, these methods may fail if the auxillary file is missing and the Zpectrometer FITS file does not contain the proper keyword:

• gatherOrigin
• gatherObject
• gatherTelescope
• gatherObsID
• gatherProjectID
• gatherScanNumber

Finally, the ZpectrometerDataClass will also need new public access methods as well, such as:

• getNumberOfRows
• getBackendValue( rowNumber, columnName )

Output SDFITS Structure Classes

Two new classes, ZBinaryHDU.py and ZPrimaryHDU.py, need to be created. These will be modelled on the existing BinaryHDU.py and PrimaryHDU.py.

The primary difference in ZPrimaryHDU.py will simply be the value of FITSVER for version control purposes. ZBinaryHDU.py will differ from BinaryHDU.py in that the output SDFITS binary table structure will inherit all of the fields found in the input Zpectrometer FITS file and add the additional fields discussed in this MR. In the existing BinaryHDU.py, the full structure of the output SDFITS binary table is described and created in that code. By using the input Zpectrometer FITS files as the starting point in describing the output structure this code should be robust to many changes in the Zpectrometer FITS file. Additions of new keywords or the renaming of keywords not mentioned in this MR will not have any impact on the workings of the sdfits tool. That information will continue to be carried along by the sdfits tool without any additional programming effort.

Application Level Classes

SDFITSWriter Class

Changing this class to write Zpectrometer SDFITS files should not be too difficult.

The above-mentioned ZpectrometerScanData class will be used in place of the ScanData class.

The writeBank method should be branched off so as to avoid the iteration through sampler, integration and phases. Instead, the iteration should simply go through the rows in the Zpectrometer FITS file.

A new 'getZpectrometerRow' method (to call in place of the 'getRow' method) will be written to avoid adding more 'if' statements to the generic 'getRow' method. The 'getZpectrometerRow' method is where results from methods of the ZpectrometerScanData are paired up with their column/keyword in the SDFITS file to be written. In this method, there should be no calls to the ZpectrometerScanData object that need sampler name and or phase index, and a value of zero can be used for calls requiring the integration index.

ZpectrometerIndex Class

This class is responsible for writing the Index file in sync with the SDFITS file. There is very little to reuse from the original IndexWriter class, so this is probably a case where it will be best to just create a new class, using the original class as a template. The contents of the index file are described above in the requirements section.

5. Deployment Checklist

What has to get done to integrate this completely into the system. This checklist must be completed before Cycle Integration Testing begins.

• Since this is development to support commissioning, and will take place in a branch, there will be no Cycle Integration Testing for this MR, and no integration into the system.

• We need to generate SDFITS files that contain Zpectrometer information and get them to Andrew Baker so that he can move ahead with GBTIDL development. Use of the Zpectrometer Manager in simulation mode is acceptable.

6. Test Plan

6.1 Internal Testing

Currently there are no example data sets for the developers to use for Internal Testing. These may become available from Sept. 18, 2006, on.

• Unit Tests: once example data sets are available, they will be used to construct various unit tests in the code branch where this development will take place. Unit tests will cover both API level classes, and the final sdfits application.

• Simulator Tests: example data sets will hopefully be produced through use of the simulator and the Zpectrometer hardware in the Jansky Lab from Sept. 18, 2006, onward. These will most likely contain a lot of nonsense data, but the developers will have to work with what they get for Internal Testing.

6.2 Sponsor Testing

Although KarenONeil is the NRAO sponsor for this MR, Andrew Baker will be doing the calibration in GBTIDL during commissioning. Therefore, sponsor testing will involve both Karen and Andrew determining that the product of the modified sdfits tool has sufficient information so that when it is imported into GBTIDL using the the methods described in ModificationRequest5C606, it can be calibrated.

It should also be noted that commissioning does not start until October 1, 2006, so this MR's status will never move beyond "Ready for Sponsor Testing" during Cycle 6.

6.3 Integration/Regression Tests

This development will be taking place in a branch of Sparrow, therefore there is no need for Integration/Regression testing.

Signatures

APPROVED: I acknowledge that my request is fully contained in this MR, and if the SDD delivers exactly what I specified, I will be happy.

ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.

Written	- BobGarwood - Sept 13, 2006
Checked	- PaulMarganian - Sept 13, 2006
Approved by Sponsor	- KarenONeil - 18 Sep 2006
Approved by Sponsor	- AndrewBaker - 19 Sep 2006
Approved by Interested Party	- KevinRauch - 21 Sep 2006
Approved by CCC	- RonMaddalena - 2 Oct2006
Accepted/Delivered by Sponsor	symbol - name - date

Symbols:

• Use %X% if MR is not complete (will display )
• Use %Y% if MR iscomplete (will display )

CCC Discussion Area

Both MR's involve the creation of a new software branch. The branch is only meant, for now, for a single customer -- those commissioning the Zpectrometer. Since it's a separate branch, with its own executables, there is no interaction of this work with existing software and our standard users. There are also statements to the affect that this branch will be in development for some months. The branch may or may not be collapsed into our production software but that decision won't happen for many months.

It's possible we may want to review this software at the time the branch is collapsed. But, until then, there shouldn't be any interactions or consequences of the work on any of our users or systems.

Appendix A: Structure of Zpectrometer SDFITS file

The Zpectrometer SDFITS file format consists of an unnamed primary HDU and one binary table. (An example Zpectrometer SDFITS file can be found here.)

The primary HDU looks like this:

SIMPLE  =                    T / file does conform to FITS standard
BITPIX  =                   16 / number of bits per data pixel
NAXIS   =                    0 / number of data axes
EXTEND  =                    T / FITS dataset may contain extensions
COMMENT   FITS (Flexible Image Transport System) format is defined in 'Astronomy
COMMENT   and Astrophysics', volume 376, page 359; bibcode: 2001A&A...376..359H
ORIGIN  = 'Fits writer WASP2'  / Program that wrote the file
END

The binary table's header describes a 'single dish' EXTNAME, with 84 columns of data:

XTENSION= 'BINTABLE'           / binary table extension
BITPIX  =                    8 / 8-bit bytes
NAXIS   =                    2 / 2-dimensional binary table
NAXIS1  =                 3425 / width of table in bytes
NAXIS2  =                    2 / number of rows in table
PCOUNT  =                    0 / size of special data area
GCOUNT  =                    1 / one data group (required keyword)
TFIELDS =                  105 / number of fields in each row
TTYPE1  = 'APEREFF '           / Aperture efficiency
TFORM1  = 'D       '           / data format of field: 8-byte DOUBLE
TTYPE2  = 'ATTEN0  '           / Gain attenuation
TFORM2  = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT2  = 'dB      '           / physical unit of field
TTYPE3  = 'AZDELTA '           / Azimuth pointing correction
TFORM3  = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT3  = 'deg     '           / physical unit of field
TTYPE4  = 'AZIMUTH '           / Azimuth
TFORM4  = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT4  = 'deg     '           / physical unit of field
TTYPE5  = 'AZREF   '           / Reference azimuth offset
TFORM5  = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT5  = 'deg     '           / physical unit of field
TTYPE6  = 'BACKEND '           / backend name
TFORM6  = '32A32   '           / data format of field: ASCII Character
TTYPE7  = 'BEADDR0 '           / Logical backend address
TFORM7  = '32A32   '           / data format of field: ASCII Character
TTYPE8  = 'BEAMEFF '           / Main beam efficiency
TFORM8  = 'D       '           / data format of field: 8-byte DOUBLE
TTYPE9  = 'BECLIP0 '           / Backend active channel range
TFORM9  = '32A32   '           / data format of field: ASCII Character
TTYPE10 = 'BEENAB0 '           / Backend status
TFORM10 = 'L       '           / data format of field: 1-byte LOGICAL
TTYPE11 = 'BEINDEX '           / Index of associated backend
TFORM11 = 'J       '           / data format of field: 4-byte INTEGER
TTYPE12 = 'BENLFN0 '           / Non-linearity correction term
TFORM12 = '32A32   '           / data format of field: ASCII Character
TTYPE13 = 'BETSYS0 '           / Backend-specific system temp
TFORM13 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT13 = 'K       '           / physical unit of field
TTYPE14 = 'BETYPE0 '           / Logical backend type
TFORM14 = '32A32   '           / data format of field: ASCII Character
TTYPE15 = 'BMAJ    '           / Beam major axis
TFORM15 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT15 = 'deg     '           / physical unit of field
TTYPE16 = 'BMIN    '           / Beam minor axis
TFORM16 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT16 = 'deg     '           / physical unit of field
TTYPE17 = 'BPA     '           / Beam position angle
TFORM17 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT17 = 'deg     '           / physical unit of field
TTYPE18 = 'BREF    '           / Gal. Lat. OFF position
TFORM18 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT18 = 'deg     '           / physical unit of field
TTYPE19 = 'CACTIME '           / Cold cal integration time
TFORM19 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT19 = 's       '           / physical unit of field
TTYPE20 = 'CAHTIME '           / Hot cal integration time
TFORM20 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT20 = 's       '           / physical unit of field
TTYPE21 = 'CALFILE '           / SDFITS output file for cals
TFORM21 = '32A32   '           / data format of field: ASCII Character
TTYPE22 = 'CAZTIME '           / Zero cal integration time
TFORM22 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT22 = 's       '           / physical unit of field
TTYPE23 = 'CCSCAN0 '           / Cold cal scan number
TFORM23 = 'J       '           / data format of field: 4-byte INTEGER
TTYPE24 = 'CDELT1  '           / Axis increment
TFORM24 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT24 = 'deg     '           / physical unit of field
TTYPE25 = 'CFFILE0 '           / Freq. calibration file
TFORM25 = '32A32   '           / data format of field: ASCII Character
TTYPE26 = 'CHOPFREQ'           / Chopping frequency
TFORM26 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT26 = 'Hz      '           / physical unit of field
TTYPE27 = 'CHOPWAIT'           / Chop blanking time
TFORM27 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT27 = 's       '           / physical unit of field
TTYPE28 = 'CHSCAN0 '           / Hot cal scan number
TFORM28 = 'J       '           / data format of field: 4-byte INTEGER
TTYPE29 = 'CLASSOUT'           / Write CLASS files
TFORM29 = 'L       '           / data format of field: 1-byte LOGICAL
TTYPE30 = 'CRPIX1  '           / Reference pixel
TFORM30 = 'D       '           / data format of field: 8-byte DOUBLE
TTYPE31 = 'CRVAL1  '           / Value at ref. pixel
TFORM31 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT31 = 'deg     '           / physical unit of field
TTYPE32 = 'CTSCAN0 '           / Temperature cal scan number
TFORM32 = 'J       '           / data format of field: 4-byte INTEGER
TTYPE33 = 'CTYPE1  '           / Axis type description
TFORM33 = '32A32   '           / data format of field: ASCII Character
TTYPE34 = 'CUNIT1  '           / Axis unit
TFORM34 = '32A32   '           / data format of field: ASCII Character
TTYPE35 = 'CWFREQ0 '           / reference channel frequency
TFORM35 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT35 = 'Hz      '           / physical unit of field
TTYPE36 = 'CWRES0  '           / channel-to-channel spacing
TFORM36 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT36 = 'Hz      '           / physical unit of field
TTYPE37 = 'CWSCAN0 '           / cwsigs scan range
TFORM37 = '32A32   '           / data format of field: ASCII Character
TTYPE38 = 'CZSCAN0 '           / Zero cal scan number
TFORM38 = 'J       '           / data format of field: 4-byte INTEGER
TTYPE39 = 'DATA    '           / Data array
TFORM39 = '256E    '           / data format of field: 4-byte REAL
TUNIT39 = 'counts/cycle'       / physical unit of field
TTYPE40 = 'DATE-OBS'           / FITS Y2K date
TFORM40 = '32A32   '           / data format of field: ASCII Character
TTYPE41 = 'DECREF  '           / Dec. OFF position
TFORM41 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT41 = 'deg     '           / physical unit of field
TTYPE42 = 'DEFCOLD '           / Cold type for tcold=-1
TFORM42 = '32A32   '           / data format of field: ASCII Character
TTYPE43 = 'DEFHOT  '           / Hot type for thot=-1
TFORM43 = '32A32   '           / data format of field: ASCII Character
TTYPE44 = 'DEWPOINT'           / The dew point
TFORM44 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT44 = 'K       '           / physical unit of field
TTYPE45 = 'DIAGOUT '           / Write diagnostic files
TFORM45 = 'L       '           / data format of field: 1-byte LOGICAL
TTYPE46 = 'DIODE   '           / Active noide diode
TFORM46 = 'J       '           / data format of field: 4-byte INTEGER
TTYPE47 = 'ELDELTA '           / Elevation pointing correction
TFORM47 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT47 = 'deg     '           / physical unit of field
TTYPE48 = 'ELEVATIO'           / Elevation
TFORM48 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT48 = 'deg     '           / physical unit of field
TTYPE49 = 'ELREF   '           / Reference elev. offset
TFORM49 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT49 = 'deg     '           / physical unit of field
TTYPE50 = 'EQUINOX '           / Equinox year
TFORM50 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT50 = 'yr      '           / physical unit of field
TTYPE51 = 'ETAFSS  '           / Forward spillover
TFORM51 = 'D       '           / data format of field: 8-byte DOUBLE
TTYPE52 = 'ETAL    '           / Rear spillover
TFORM52 = 'D       '           / data format of field: 8-byte DOUBLE
TTYPE53 = 'EXPOSURE'           / Effective integration time
TFORM53 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT53 = 's       '           / physical unit of field
TTYPE54 = 'FACILITY'           / local observatory params
TFORM54 = '32A32   '           / data format of field: ASCII Character
TTYPE55 = 'FITSFILE'           / SDFITS format output file
TFORM55 = '32A32   '           / data format of field: ASCII Character
TTYPE56 = 'FOFFSET '           / Frequency offset
TFORM56 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT56 = 'Hz      '           / physical unit of field
TTYPE57 = 'FREQRES '           / Frequency resolution
TFORM57 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT57 = 'Hz      '           / physical unit of field
TTYPE58 = 'FRONTEND'           / Frontend name
TFORM58 = '32A32   '           / data format of field: ASCII Character
TTYPE59 = 'HUMIDITY'           / Relative humidity
TFORM59 = 'D       '           / data format of field: 8-byte DOUBLE
TTYPE60 = 'IMAGFREQ'           / Image sideband frequency
TFORM60 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT60 = 'Hz      '           / physical unit of field
TTYPE61 = 'IMREF   '           / Image freq in rest frame
TFORM61 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT61 = 'Hz      '           / physical unit of field
TTYPE62 = 'LAGS    '           / the lags array
TFORM62 = '256J    '           / data format of field: 4-byte INTEGER
TUNIT62 = 'counts  '           / physical unit of field
TTYPE63 = 'LREF    '           / Gal. Long. OFF position
TFORM63 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT63 = 'deg     '           / physical unit of field
TTYPE64 = 'LST     '           / LST at start of scan
TFORM64 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT64 = 's       '           / physical unit of field
TTYPE65 = 'MASTER  '           / Index of master backend
TFORM65 = 'J       '           / data format of field: 4-byte INTEGER
TTYPE66 = 'MOLECULE'           / Spectral line identifier
TFORM66 = '32A32   '           / data format of field: ASCII Character
TTYPE67 = 'NBE     '           / Number of backend devices
TFORM67 = 'J       '           / data format of field: 4-byte INTEGER
TTYPE68 = 'NODTIME '           / Nod time per side
TFORM68 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT68 = 's       '           / physical unit of field
TTYPE69 = 'NODWAIT '           / Nod blanking time
TFORM69 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT69 = 's       '           / physical unit of field
TTYPE70 = 'OBSFREQ '           / Observed frequency
TFORM70 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT70 = 'Hz      '           / physical unit of field
TTYPE71 = 'OBSMODE '           / Observing mode
TFORM71 = '32A32   '           / data format of field: ASCII Character
TTYPE72 = 'POLARIZ '           / Polarization description
TFORM72 = '32A32   '           / data format of field: ASCII Character
TTYPE73 = 'RAREF   '           / RA OFF position
TFORM73 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT73 = 'h       '           / physical unit of field
TTYPE74 = 'REFRAC  '           / Refraction correction
TFORM74 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT74 = 'arcsec  '           / physical unit of field
TTYPE75 = 'RESTFREQ'           / Rest frequency
TFORM75 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT75 = 'Hz      '           / physical unit of field
TTYPE76 = 'RVSYS   '           / Source radial velocity
TFORM76 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT76 = 'm/s     '           / physical unit of field
TTYPE77 = 'SBRATIO '           / Sideband ratio
TFORM77 = 'D       '           / data format of field: 8-byte DOUBLE
TTYPE78 = 'SCAN    '           / Scan ID number
TFORM78 = 'J       '           / data format of field: 4-byte INTEGER
TTYPE79 = 'SIGSFILE'           / SDFITS output file for CWSIGS
TFORM79 = '32A32   '           / data format of field: ASCII Character
TTYPE80 = 'SITEELEV'           / Site elevation
TFORM80 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT80 = 'm       '           / physical unit of field
TTYPE81 = 'SITELAT '           / Site latitude
TFORM81 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT81 = 'deg     '           / physical unit of field
TTYPE82 = 'SITELONG'           / Site longitude
TFORM82 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT82 = 'deg     '           / physical unit of field
TTYPE83 = 'TAMBIENT'           / Ambient temperature
TFORM83 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT83 = 'K       '           / physical unit of field
TTYPE84 = 'TAU     '           / Atmospheric opacity (obs)
TFORM84 = 'D       '           / data format of field: 8-byte DOUBLE
TTYPE85 = 'TAUIMAGE'           / Atmospheric opacity (image)
TFORM85 = 'D       '           / data format of field: 8-byte DOUBLE
TTYPE86 = 'TAUZENIT'           / Opacity at zenith
TFORM86 = 'D       '           / data format of field: 8-byte DOUBLE
TTYPE87 = 'TCAL    '           / Calibration temperature
TFORM87 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT87 = 'K       '           / physical unit of field
TTYPE88 = 'TCALTYPE'           / Calibration algorithm
TFORM88 = '32A32   '           / data format of field: ASCII Character
TTYPE89 = 'TCOLD   '           / Cold load temperature
TFORM89 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT89 = 'K       '           / physical unit of field
TTYPE90 = 'TDIM    '           / DATA axis dimensions
TFORM90 = '32A32   '           / data format of field: ASCII Character
TTYPE91 = 'TEMPSCAL'           / Temperature scale
TFORM91 = '32A32   '           / data format of field: ASCII Character
TTYPE92 = 'THOT    '           / Hot load temperature
TFORM92 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT92 = 'K       '           / physical unit of field
TTYPE93 = 'TRANSITI'           / Spectral transition
TFORM93 = '32A32   '           / data format of field: ASCII Character
TTYPE94 = 'TRX     '           / Receiver temperature
TFORM94 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT94 = 'K       '           / physical unit of field
TTYPE95 = 'TSYS    '           / System temperature
TFORM95 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT95 = 'K       '           / physical unit of field
TTYPE96 = 'USEROUT '           / Write user-defined files
TFORM96 = 'L       '           / data format of field: 1-byte LOGICAL
TTYPE97 = 'USERTYPE'           / User channel data format
TFORM97 = '32A32   '           / data format of field: ASCII Character
TTYPE98 = 'VELDEF  '           / Velocity definition
TFORM98 = '32A32   '           / data format of field: ASCII Character
TTYPE99 = 'VFRAME  '           / Frame radial velocity
TFORM99 = 'D       '           / data format of field: 8-byte DOUBLE
TUNIT99 = 'm/s     '           / physical unit of field
TTYPE100= 'VLOAD   '           / Calibration load voltage
TFORM100= 'D       '           / data format of field: 8-byte DOUBLE
TUNIT100= 'mV      '           / physical unit of field
TTYPE101= 'VOFFSET '           / Velocity offset
TFORM101= 'D       '           / data format of field: 8-byte DOUBLE
TUNIT101= 'm/s     '           / physical unit of field
TTYPE102= 'VSOURCE '           / Nominal source velocity
TFORM102= 'D       '           / data format of field: 8-byte DOUBLE
TUNIT102= 'm/s     '           / physical unit of field
TTYPE103= 'WASPFITS'           / SDFITS includes WASP keywords
TFORM103= 'L       '           / data format of field: 1-byte LOGICAL
TTYPE104= 'WINDDIRE'           / Wind direction
TFORM104= 'D       '           / data format of field: 8-byte DOUBLE
TUNIT104= 'deg     '           / physical unit of field
TTYPE105= 'WINDSPEE'           / Wind speed
TFORM105= 'D       '           / data format of field: 8-byte DOUBLE
TUNIT105= 'm/s     '           / physical unit of field
EXTNAME = 'single dish'        / name of this binary table extension
EXTVER  =                    1 / Table version number
OBJECT  = 'Orion A '           / Object name
OBSERVER= 'I. M. Astronomer'   / Observer name
OBSID   = 'Orion A Map'        / Observation ID
OBSNUM  =                    1 / Observation number
PROJID  = 'Orion Survey'       / Project identification
TELESCOP= 'ATTBL 7M'           / Telescope name
TIMESYS = 'UTC     '           / Time system
SCANRNGE= '16-17   '           / scan number range

END

• dobstest.fits: Sample Zpectrometer SDFITS file

Attachment:	Action:	Size:	Date:	Who:	Comment:
ZpectDataCapture.jpg	action	42947	18 Sep 2006 - 17:28	BobGarwood	Zpectrometer Data Capture Diagram
dobstest.fits	action	37440	15 Sep 2006 - 15:41	BobGarwood	Sample Zpectrometer SDFITS file