Introduction

For completeness' sake, we include here a description of the raw data averaging software, called CONSTRICTOR, which produces the input files for $\cal OYST\!ER\,$. CONSTRICTOR is written in C, but uses a mixed C and FORTRAN library for HDS file access. (This library is described in the $\cal OYST\!ER\,$ 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, $\cal OYST\!ER\,$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 $\cal OYST\!ER\,$'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.