For completeness' sake, we include here a description of the raw data
averaging software, called CONSTRICTOR, which produces the input files
for
. CONSTRICTOR is written in C, but uses a mixed C and FORTRAN
library for HDS file access. (This library is described in the
manual.)
CONSTRICTOR reads NPOI raw data files and observation logs, and decodes and integrates data such as visibilities, delays, photon rates, etc. NPOI raw data is written by the embedded system in form of packets, with different types depending on which data they hold. The packet definitions are contained in packetdefs.h. The packet headers, all conforming to the same format, contain information as to the type of the packet, its length and a time stamp.
CONSTRICTOR first reads the packet headers from all raw files associated
with one night of observing and creates a combined packet directory in
which all packets are in chronological order. Packet directories for the
individual raw files are stored on disk (working directory), and can
be read later for a faster restart on CONSTRICTOR should that become
necessary. (More recently,
has been upgraded to create these
auxiliary files for CONSTRICTOR with the added benefit of additional
data integrity checks.) CONSTRICTOR then reads the FILE_HEADER and
SYS_CONFIG packets for date and configuration information. It then
proceeds to process all packets whose time stamps fall in between
start and stop times defined in the input parameter file. The packets
of the high rate data types, FRINGE_DATA (or BG_DATA for 6-way data),
FDL_POSITION, and NAT_COUNTS, are processed by the fringeav.c,
fdlav.c, and natav.c modules, respectively. Individual 2ms
records of these packets are aligned (synchronized), and missing matches
discarded. The integration length is defined by the number of records,
not by a time interval. This is a pecularity which one has to keep
in mind especially when reducing data for nights with very bad seeing.
In earlier versions of CONSTRICTOR, it was enabled to do both incoherent
and coherent integrations of the visibilities. Since the latter has never
worked well, this capability has been removed and is now part of
's
COBRA procedures. The lean version of CONSTRICTOR therefore serves two
purposes now: provide an output file with incoherently averaged data,
and, optionally, reformat the raw data and store individual scans in
separate HDS files for COBRA.