This page is intended as a start page for discussions, whishlists and notes about a Second Version of the OI-FITS format

suggestions

I start with a list of suggestions collected in the JMMC working groups.

1. Correlated Fluxes:
   • needed for, e.g., model fitting.
   • either through the use of VISDATA, VISERR (present in ESO's AMBER format and described here). These are Double precision Complex values representing the correlated fluxes. Questions:
     • What noise model to adopt (normally same noise model as sketched in the OI-FITS publication)?
     • Normally there should also be a Nchan*Nchan VISCOV representing the covariances?
   • or through the presence of a OI_SPECTRUM table containing the total fluxes such that flux^2*vis2=correlated_flux^2
   • or both? In all cases the noise model should be very precise.
2. Calibrator vs. Science Object tagging. To have a sequence of calibrators and objects in a OI-FITS. Calibrator may just be that there is a diameter in mas in the OI_TARGET, but then:
   • • is this a UD or LD
     • if UD, for which lambda, etc...
3. Keyword indicating wether the OI-FITS is made of 'instantaneous (raw) visibilities', 'time-averaged (raw) visibilities' or 'calibrated visibilities'. This because for example in AMBER data reduction one can get any of these (the 'instantaneous' being an oi-fits with 1000+ visibilities on 128+ channels, taken every 10 ms), and it would be useful to have this info for, e.g., model fitting.
4. There is a need to define more accurately what is complex visibility. It may be obtained with dual-field interferometry, but is more often estimated from dispersed fringes using differential phase or cross-spectrum. We have no information on how the reference channel is chosen. It may be a particular spectral band, e.g. chosen in a continuum (VEGA), or all the available spectral channels but the one to be referenced (AMBER). Not easy to build a good model of the data. -- MichelTallon - 16 Sep 2010.

Comment by JorgUwe.Pott: what about the origin of the diameter above? Comes from a catalog, is subject to change (catalog change or new measurement), should we have an indirection to the originating catalog, etc... To be quite accurate would certainly complicate the OI-FITS.

Comment by Gilles.Duvert: yes, but for practical purposes, having the calibrator diameter (say, "implied, supposed or forced diameter by the person responsible of originating the OI-FITS") is very handy for data reduction (especially pipelines), model fitting etc... Perhaps it is not necessary to go into more details, and just impose an UD for the observation band. Now that I think of it, the only way to have an UD for multi-band data (AMBER being an example) would be to have an UD vector, one per spectral channel.

Comment by JohnYoung - 6 Oct 2010: raw/time-averaged/calibrated is probably not precise enough, but it depends why you want this information - surely only 'calibrated' is useful for model-fitting? In general there may be several calibration steps, some of which could be applied before time-averaging.

features of the current format

Some features of the current format may perhaps need to be rephrased, or precised, to avoid implementation problems. I list a few remarks gathered:

1. The possibility to have NULLS for some unavailable feature (like VISAMP) and not for some others has triggered problems in some OI-FITS readers, who relied on the presence of the FLAGS only.
2. It seems to me more convenient to have ALL the available stations of an interferometer listed in the OI_ARRAY, always in the same order, so that all OI-FITS files produced by the same interferometer will have the same sta_index for the same station.
3. To have also the 'equatorial local' coordinate frame possible in OI_ARRAY
4. Strictly speaking, OI_ARRAY table and STA_INDEX columns are not useful for calibrated OI-FITS, since the values have 'forgotten' the interferometer on which they were taken?

Comments by LaurentBourges: In general, the OIFits specification does not contain enough explicit rules about table data using keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" (see RFC 2119. For example :

• OI_ARRAY tables are optional and ARRNAME keywords are optional too, but there is no rule about the STA_INDEX values (0, NULL, anything else). Proposed rule : If the OIFits file does not have any OI_ARRAY, the ARRNAME keyword value in data tables MUST NOT be present and STA_INDEX values MUST be set to NULLS.
• OI_TARGET/TARGET_ID and OI_ARRAY/STA_INDEX use integer (signed or unsigned). Proposed rule : these values must be greater or equal to 1
• The specification should indicate which table columns are mandatory (required values) or optional (NULLS allowed).
• If a feature is missing because the instrument/data processing can not provide it, there is two solution :
  • remove the entire column
  • or keep the column but set values to NULLS
• Idem for table keywords : Which of them are mandatory or optional (empty string or NULL) ?

Comments by MichelTallon - 16 Sep 2010:

• In the specifications, NULLS on amplitudes are explicitely introduced for T3. It seems that we can also use it for VIS, but this could be explicitely specified.
• There is no way to indicate that only the phase of a complex value is meaningless.
• Two different methods are available to cancel data: NULLS (at least on amplitude), and flags (but for the whole complex datum, both amplitude and phase). Using separate flags for amplitude and phase, or only NULLS, could be more straightforward. Do we need two methods ? Why ?

Comments by JohnYoung - 6 Oct 2010:

• STA_INDEX is useful for calibrated data even if the OI_ARRAY is not present, since it allows data to be grouped by baseline/triangle for plotting.
• Regarding NULLs versus removing column, it depends whether we want to be backwards-compatible with existing software that reads OIFITS 1. These codes are likely to break if an expected column is missing, even if the values are not used for anything after being read.

Proposal for revision 2 of OI_TARGET

Proposed by: ChristianHummel - 6 Oct 2010:

I propose to include the following information in the second revision: limb darkened diameter (DIAMETER), v*sin(i) (VSINI), angular rotational velocity in units of the breakup (OMEGA), tilt of the rotational axis to the line of sight (TILT), position angle of the rotational axis on the sky (RAPA), polar effective temperature (TEFF), polar effective gravity (LOGG), stellar mass (MASS), von Zeipel exponent (ZEXP), flux and linear limb darkening coefficient as a function of wavelength (FLUX, LLDC, WAVE).

This information is the minimum to allow users to compute visibilities of moderately resolved calibrators, including rotation. This would be useful for observations on very long baselines (such as CHARA in the optical) where truly unresolved calibrators don't exist. The information contained in the OI_TARGET table should correspond to the visibilities computed for the calibration of the science targets. This would also allow re-calibration in case a diameter (for example) has been found in error. Fairly simple formulas exist for the computation of visibilities for limb darkened disks. Because the new format would allow to store spectra, the relevant quantities can be integrated over any bandpass.

With respect to models of rotating stars, the information we provide would be sufficient to compute simple models (just about any which has been published so far on Altair, Regulus, Alderamin). Code is available so far as part of OYSTER, and hopefully in other packages too in the not too distant future. At the same time, we would be able to store the SED of a target, for use in advanced multi-wavelength modeling and imaging algorithms.

I have modified John Monnier's OIFITS IDL scripts to implement the revision, and a sample table can be downloaded from http://www.eso.org/~chummel/downloads/downloads.html with data from Jinmi Yoon et al. 2007 (priv. comm.)

Comments by JohnYoung - 6 Oct 2010: Do we expect this version to be adopted by CHARA, since John Monnier is pursuing an alternative solution using images as calibrator models? If not how important is it to support rotating stars - I would have thought only CHARA and MROI (eventually) would need to use rotating stars as calibrators?

TWiki - How to Register

• Register here: To modify these Wiki pages you need to be registered. This takes one minute!

-- GillesDuvert - 13 Sep 2010

• OI_FITS.pdf: ESO's Interferometric data format (contains OI-FITS)