Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.mrao.cam.ac.uk/projects/OAS/oi_data/DataExStd_rel2_apr02_letter.pdf Дата изменения: Fri Jan 11 15:22:06 2008 Дата индексирования: Sat Mar 1 02:29:10 2014 Кодировка: Поисковые слова: earth's atmosphere

Preliminary Draft
A Data Exchange Standard for Optical/IR Interferometry
Prepared by NPOI and COAST
First Version: 10 January 2001 Last Update: 25 April 2002

1 Introduction
Considering the number of optical and infrared interferometers in operation or under construction it seems imperative that a standard be established which will allow the exchange of data among various groups. As a first step, we should try to agree on a standard for exchanging calibrated data. By first concentrating on calibrated data we only need those instrumental parameters which are required to characterize the data for subsequent analysis. Our ultimate goal is to cast the standard as a FITS file format definition, but first we should agree on what s hould be included in the standard. The initial document is designed to standardize the exchange of imaging data, but does not preclude the possibility of including other types of data in the future (e.g. astrometry data). Jaffe and Cotton have been working on a FITS file format for use with the VLTI backends. While the Jaffe and Cotton document contains elements to handle the storage of raw data, many of their elements are also needed for general data exchange. In this document we summarize the information we think is needed for data exchange. Document Conventions In what follows we have tried to follow the FITS binary table usage of keywords and column headings. The keywords can be considered as scalars, while the columns can be simply an array, or an array of pointers to other arrays. Allowed data types are: I = integer (16-bit), A = character, E = real (32-bit), D = double (64-bit), L = logical, M = complex (2 64-bit). The number in parentheses is the dimensionality of the entry. Mandatory keywords describing the structure of the FITS binary tables have been omitted (see "Definition of The Flexible Image Transport System"). The reference also describes various extensions to binary tables that are not part of the FITS standard. None of these are currently used in this format. The revision numbers of all tables are currently zero. After a suitable amount of discussion and consequent changes, the table definitions will be "frozen", and assigned revision numbers of one. Further changes will require increments in the appropriate revision numbers. Page 1


This document uses US English spellings.

2 Definitions and Assumptions
Baseline vector The baseline vector between two interferometric stations A and B whose position vectors are xA and xB is defined as AB = x B - x A . UV coordinates u is the East component and v is the North component of the projection of the baseline vector onto the plane normal to the direction of the phase center, which is assumed to be the pointing center. Visibility The basic observable of an interferometer is the visibility, which is related to the sky brightness distribution I(x,y) by a Fourier Transform: -2 i( ux + vy ) V (u, v ) = dx dy I (x , y)e x and y are displacements (in radians) in the plane of the sky (which is assumed to be flat). The origin of this coordinate system is the phase center. x is in the direction of increasing right ascension (i.e. the x axis points East), and y is in the direction of increasing declination (the y axis points North). With x and y defined, the above equation defines the sign convention for complex visibilities that should be used in the data format. The visibility is normalized by the total flux from the ta rget, which is assumed to remain constant over the time spanned by the measurements in the file. Neither the field of view over which the "total" flux is collected, or the field of view over which fringes are detected (i.e. the limits of the above integral), can be inferred from the data file. Triple product The triple product, strictly the bispectrum, is the product of the visibilities on the baselines forming a closed loop joining three stations A, B and C. In the following expression, (u1, v1) is the projection of AB and (u2, v 2) is the projection of BC (and hence (u1+u2, v 1+v 2) is the projection of AC):
T (u1 , v1,u2 , v
2

)

= V (u1, v1 )V (u2 , v2 )V (u1 +u2 , v1 +v


2

)

Noise model for triple product The data are assumed to be complex triple products averaged over a large number of "exposures". In such a case, the noise can be fully described in terms of a Gaussian noise ellipse in the complex plane. Photon, detector and background noise tend to lead to noise ellipses that are close to circular. On the other hand, fluctuating atmospheric phase errors Page 2


across telescope apertures typically cause fluctuations product which are much larger than the fluctuations in contribution to the noise ellipse is elongated along the product vector in the Argand diagram, as shown in the
2

in the amplitude of the triple the phase. Thus the "atmospheric" direction of the mean triple figure. Such noise needs to be

characterised in terms of the variance perpendicular to the mean triple product vector T and the variance || parallel to T . We can parameterize the perpendicular variance in terms of a "phase error" = (180 / )( / T ) . The phase error gives an approximate value for the rms error in the closure phase in degrees. We denote || as the "amplitude error". Imaginary
2

Noise ellipse



||

T





Real In many cases, the observer may be interested primarily in the closure phase and not the triple product amplitude, and therefore may choose not to calibrate the amplitude. Such a case can be indicated in the above notation as an infinite amplitude error and a finite phase error. The data format specifies that such a case should be indicated by a NULL value for the amplitude (the amplitude error value is then ignored).

3 FITS File Structure
A valid exchange -format FITS file must contain an OI_ARRAY table, an OI_TARGET table, an OI_WAVELENGTH table, and at least one of the visibility tables: OI_VIS, OI_VIS2, or OI_T3. The tables must appear in the order gi ven above.

Page 3


4 Tables Defined by the Standard
OI_ARRAY revision 0 As defined, this table is aimed at ground -based interferometry with separated telescopes. Alternative tables could be used for other cases. Keywords REVISION ARRNAM FRAME ARRAYX ARRAYY ARRAYZ DATE-OBS A Start date of observations D Array center coordinates (meters)

I A A

Revision number of the table definition Array Name Coordinate Frame

Column Headings (one row for each telescope) TEL_NAME A (8) Telescope name STA_NAME A (8) Station name INDEX STAXYZ I (1) Station number DIAMETER E (1) Element diameter (meters) D (3) Station coordinates relative to array center (meters)

Number of elements There is no keyword giving the number of elements (NELEMENT in the previous revision of this document), as this is equal to the number of rows in the FITS binary table, which is given by the standard NAXIS2 keyword. For the same reason, there are no format-specific keywords giving the number of rows in any of the other tables. Coordinate frame If the FRAME keyword has the value "GEOCENTRIC", then the coordinates are given in an earth-centered, earth-fixed, Cartesian reference frame. The origin of the coordinates is the earth's centre of mass. The z axis is parallel to the direction of the conventional origin for polar motion. The x axis is parallel to the direction of the intersection of the Greenwich meridian with the mean astronomical equator. The y axis completes the righthanded, orthogonal coordinate system. Currently, no other values for the FRAME keyword may be used. This will change if the need arises.

Page 4


Array coordinates The ARRAYX, ARRAYY, and ARRAYZ keywords shall give the coordinates of the array center in the coordinate frame specified by the FRAME keyword. Element coordinates in the main part of the table are given relative to the array center, in the same coordinate frame. Coordinates are given in meters. Start date of observations This shall be a UTC date in the format YYYY- MM-DD, e.g. "1997-07-28". Station number Each row in the table shall be assigned a unique station number, which shall be used in other tables as an index into this one. The table structure is the simplest possible i.e. there is no explicit concept of different "configurations" within the ta ble. Each row in the table shall correspond to a distinct set of station coordinates used in taking the data stored in the file. Element diameter This is the effective aperture size, e.g. if the telescope is stopped down. OI_TARGET Keywords RE VISION revision 0

I

Revision number of the table definition

Column Headings (one row for each source) TARGET_ID I (1) TARGET RAEPP DECEPP EQUINOX RAAPP DECAPP RA_ERR DEC_ERR SYSVEL VELTYP VELDEF Index number A (16) Target name D (1) RA at mean equinox (degrees) D (1) DEC at mean equinox (degrees) E (1) Equinox D (1) Apparent RA at beginning of observation (degrees) D (1) Apparent DEC at beginning of observation (degrees) D (1) Error in apparent RA (degrees) D (1) Error in apparent DEC (degrees) D (1) Systemic radial velocity (meters per second) A (8) Reference for radial velocity (`LSR', `GEOCENTR', etc.) A (8) Definition of radial velocity (`OPTICAL', `RADIO')

Page 5


PMRA PMDEC

D (1) Proper motion in RA (degrees per year) D (1) Proper motion in DEC (degrees per year)

PMRA_ERR D (1) Error of proper motion in RA (degrees per year) PMDEC_ERR D (1) Error of proper motion in DEC (degrees per year) PARALLAX E (1) Parallax (degrees) PARA_ERR E (1) Error in parallax (degrees) SPECTYP A (16) Spectral type

Target positions The RAEPP and DECEPP columns shall contain the right ascension and declination respectively of the phase center at the standard mean epoch, in degrees. The phase center is assumed to be the pointing center. The EQUINOX field shall contain a (floating point) Julian year giving both the epoch of the position and the equinox for the celestial coordinate system in which the position is expressed. The RAAPP and DECAPP columns shall contain the right ascension and declination respectively of the phase center at 0h UTC on DATE-OBS (from OI_ARRAY table), in degrees. The equinox for this position is also 0h on DATE-OBS. RA_ERR and DEC_ERR shall contain the one -sigma uncertainties in these quantities. The PMRA and PMDEC columns should contain the proper moti ons of the source in right ascension and declination respectively, in degrees per Julian year. If the proper motion is unknown then both fields should be set to zero. PMRA_ERR and PMDEC_ERR shall contain the one -sigma uncertainties in these quantities. PMRA and PMDEC are to be applied to the apparent positions for times other than 0h on DATE-OBS (alternatively the user can apply the appropriate transformations to the catalogue position given by RAEPP and DECEPP). This may be important for solar system objects, or when the data in the file spans a period of time much longer than a single night. Velocity Information The SYSVEL column shall give the systemic radial velocity of the target. The VELTYP column shall contain a string that specifies the frame of reference for the systemic velocities. The string shall be one of the following: LSR HELIOCEN BARYCENT GEOCENTR TOPOCENT Local Standard of Rest Relative to the SUN Solar system barycenter Center of mass of the earth Uncorrected

Page 6


The VELDEF column shall contain a string indicating the convention used for the systemic velocities. It shall be either "RADIO" or "OPTICAL". OI_WAVELENGTH Keywords REVISION revision 0

I

Revision number of the table definition

Column Headings (one row for each detector) EFF_WAVE E (NWAVE) Effective wavelength of each channel (meters) EFF_BAND E (NWAVE) Effective bandpass of each channel (metres) Wavelengths The WAVELENGTH table describes the spectral response of detectors with a number of spectral channels. If there are multiple physical detectors, the effective wavelengths/bandwidths for each should be stored in different subsets of the table rows, i.e. the table describes a single "virtual" detector. The EFF_WAVE column shall contain the best available estimate of the effective wavelength of each spectral channel, and the EFF_BAND column shall contain the best available estimate of the effective half-power bandwidth. These estimates should include the effect of the earth's atmosphere, but not the spectrum of the target (the effe ct of the target spectrum should be taken into account as part of any model-fitting/mapping process, i.e. the target spectrum is part of the model). NWAVE is the number of table rows, given by the NAXIS2 keyword. OI_VIS Keywords REVISION revision 0

I

Revision number of the table definition

Column Headings (one row for each measurement) TARGET_ID I (1) Target number as index into OI_TARGET table TIME INT_TIME VISDATA VISERR UCOORD VCOORD STATNUM D (1) UTC time of observation (seconds) D (1) Integration time (seconds) M (NWAVE) Visibility - stored as a complex number M (NWAVE) Error in Visibility (complex number) D (1) U coordinate of the data (meters) D (1) V coordinate of the data (meters) I (2) Station numbers contributing to the data

Page 7


FLAG OI_VIS2 Keywords REVISION

L (NWAVE) Flag revision 0

I

Revision number of the table definition

Column Headings (one row for each measurement) TARGET_ID I (1) Target number as index into OI_TARGET table TIME INT_TIME VIS2DATA VIS2ERR UCOORD VCOORD STATNUM FLAG OI_T3 Keywords REVISION D (1) UTC time of observation (seconds) D (1) Integration time (seconds) D (NWAVE) Squared Visibility D (NWAVE) Error in Squared Visibility D (1) U coordinate of the data (meters) D (1) V coordinate of the data (meters) I (2) Station numbers contributing to the data L (NWAVE) Flag

I

Revision number of the table definition

Column Headings (one row for each measurement) TARGET_ID I (1) Target number as index into OI_TARGET table TIME INT_TIME T3AMP T3PHI T3PHIERR U1COORD V1COORD U2COORD V2COORD STATNUM D (1) UTC time of observation (seconds) D (1) Integration time (seconds) D (NWAVE) Triple Product Amplitude D (NWAVE) Triple Product Phase in degrees D (NWAVE) Error in Triple Product Phase in degrees D (1) U coordinate of baseline AB of the triangle (meters) D (1) V coordinate of baseline AB of the triangle (meters) D (1) U coordinate of baseline BC of the triangle (meters) D (1) V coordinate of baseline BC of the triangle (meters) I (3) Station numbers contributing to the data Page 8

T3AMPERR D (NWAVE) Error in Triple Product Amplitude


FLAG

L (NWAVE) Flag

The following comments apply to one or more of the OI_VIS, OI_VIS2, and OI_T3 tables. Time of observation This shall be the mean UTC time of the measurement in seconds since 0h o n DATEOBS. Note this may take negative values, or values > 86400 seconds, and hence the epoch of observation is not restricted to DATE-OBS. Integration time The data format will normally be used for interchange of time -averaged data. The "integration time " is therefore the length of time over which the data were averaged to yield the given data point. Data arrays If the triple product amplitudes are meaningless, as is the case for COAST data, NULL values for T3AMP may be used. The closure phases should still be treated as valid. NWAVE is the number of distinct spectral channels recorded by the single "virtual" detector, as given by the NAXIS2 keyword of the OI_WAVELENGTH table. Complex visibility and visibility-squared UV coordinates UCOORD, VCOORD give the coordinates in meters of the point in the UV plane associated with the vector of visibilities. The data points may be averages over some region of the UV plane, but the current version of the Standard says nothing about the averaging process. This may change in future versions of the Standard. Triple product UV coordinates The U1COORD, V1COORD, U2COORD, and V2COORD columns contain the coordinates of the bispectrum point ­ see page 2 for details. Note that U3COORD and V3COORD are implicit. The corresponding data points may be averages in (bi-) spatial frequency space, but this version of the Standard does not attempt to describe the averaging process.

4 Optional Tables
It may be useful to allow for some optional tables. For example, there might be one that contains instrument specific information, such as the backend configuration. Another optional table could contain information relevant to astrometry.

References
Definition of the Flexible Image Transport System, NOST, 1999.

Page 9