OIFITS reader

The primary access to OYSTER procedures is via the OIFITS reader (get_oifits), which stores the data internally in the scans and other auxilliary IDL structures. Alternatively, VLTI MIDI and AMBER data can be reduced using the MyMidiGui and MyAmberGui front ends (http://www.eso.org/$\sim$chummel/midi/mymidigui/mymidigui.html,
http://www.eso.org/$\sim$chummel/amber/myambergui/myambergui.html). These provide easy to use GUIs for the externally developed data reduction softwares (MIA+EWS and amdlib), and automatically store data internally using OYSTER's data structures, as well as write data to disk in OIFITS format.

For data to be stored internally in OYSTER many requirements are to be met, mostly for historical reasons of a data package first released over 15 years ago. These procedures are handled in a mostly transparent way, but need to be kept in mind in case of adaptations of the code to specific applications. Here we point out relevant ``pecularities'' of OYSTER.

• Array information such as station names and coordinates are not strictly necessary to be present in the OIFITS data file, and models can be computed by OYSTER for them using the $uv$-coordinates. But OYSTER considers the latter as secondary data and usually computes these from the apparent star positions, observation dates and times, as well as the station coordinates. This is due to one of the original applications of OYSTER to astrometry with NPOI. In practical terms, use of astrometric routines such as calcastrom should therefore be avoided.

• Object coordinates are also not strictly necessary for the computation of model data, and thus OYSTER will read OIFITS even without the OI_TARGET table. However, internally each target must have an ID composed of a three letter catalog name (e.g. HDN or HIP), and an index into this catalog (e.g. HDN123306). This is the so-called star ID. Again this has to do with the use of OYSTER as astrometric software for NPOI. The OYSTER installation includes several tables in the starbase folder (e.g. vlti.hdn which are used for looking up catalog IDs for a given target name. If no entry can be found, the default OBJ designation is used (OBJ+HHMMSSFFDDMMSSF). This is usually not a problem except that the STARBASE procedures will not work anymore, such as compiling stellar data for the observed targets from installed catalogs.

• General configuration items, stored in the genconfig structure, will often be incomplete when reading an OIFITS file.