===================================================================================
                                SDFITS-TEST
===================================================================================

SDFITS-TEST is the on-line version of SDFITS v1.1

SDFITS-TEST runs continuously while observing and fills and appends new data to 
the *.fits output file as it comes in.  This allows you almost real-time
access to GBT data in SDFITS .fits file format. 

You can (and should!) start SDFITS-TEST running before you begin data
acquisition.  The program will wait.  Program will give you the option
of starting a new file or appending to an existing one.  Thus you have
a choice of writing a new .fits file each observing session or 
concatenating one big one.  If you do the latter, you should backup this
file after each session.

I find it most useful to have SDFITS-TEST running on its own screen.  It only
displays a single action line at the bottom of the Xwin it is running on.
It DOES have a worm that shows whether or not it is executing.

*********************************************************************************

TO RUN THE PROGRAM:

----------------------------------------------------------------------------
sdfits-test -online -mode=avg fully-qualified-GBT-dataname ditto-for-SDFITS
----------------------------------------------------------------------------

where 

'fully-qualified-GBT-dataname' -> e.g.  /home/gbtdata/AGBT02A_041_01

'ditto-for-SDFITS'             ->       /users/tbania/idl/data/jn04_d1

==>  Presumably the code works for all -mode= choices, e.g. 'raw', 'cal',
     but I only have used 'avg' which averages all the subrecords for a
     scan and performs a calibration which assumes a single Tsys for 
     each subcorrelator.

==>  SDFITS produces a uniques record for each subcorrelator.  So if you,
     say, have configured the ACS to sample 16 subcorrelators (e.g 8 
     frequencies at 2 polarizations each), you get 16 SDFITS records 
     per scan. (IN 'AVG' MODE)

==>  SDFITS-TEST will process ALL the backends it sees.  So if you are connected
     to both the ACS and the DCR you will get two files being continually updated:

     For the example above these will be called: 

     /users/tbania/idl/data/jn04_d1.avg.acs.fits

     /users/tbania/idl/data/jn04_d1.avg.dcr.fits

==>  SDFITS-TEST is always one scan behind the data acquisition.
     This is a pipeline issue; it waits until a new scan is written
     before it fetches the previous scan's data.  Pretty conservative
     approach.

-----------------------------------------------------------------------------
Known shortcoming:

SDFITS should be modified to deal with DCR data in a better way.  At
present the code produces a FITS record for *each* data point (DCR
dump).  That is, a 600 point FOCUS measurement generates 600 discrete 
FITS files in 'cal' mode which is what one needs for measuring true 
continuum intensities.  Furthermore, although the code passes in the 
FITS header parameter information regarding the nature of the measurement
(e.g. FOCUS/POINT/etc.), the total number of measurements in the observing 
sequence, and the current position of the data in the sequence, it does
NOT pass the number of data points in the scan. (!)  We have had to
write code to parse the SDFITS produced *.cal.fits files to figure
out how many data points are in each DCR scan.  This is cumbersome,
inefficient, and should not be necessary.


===============================================================================
SDFITS-TEST was written by David Fleming.  
Eric Sessoms wrote much of the infrastructure.