Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.eso.org/~chummel/oyster/manual/node21.html
Дата изменения: Tue Apr 28 19:12:49 2015
Дата индексирования: Sun Apr 10 20:23:28 2016
Кодировка:
Поисковые слова: arp 220

OIFITS reader

The primary access to $\cal OYST\!ER$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 $\cal OYST\!ER$'s data structures, as well as write data to disk in OIFITS format.

For data to be stored internally in $\cal OYST\!ER$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 $\cal OYST\!ER$.

• 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 $\cal OYST\!ER$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 $\cal OYST\!ER$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 $\cal OYST\!ER$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 $\cal OYST\!ER$as astrometric software for NPOI. The $\cal OYST\!ER$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.