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.

features of the current format

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 ?

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)