---

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.

Comment by FlorentinMillour - 26 Jul 2011: What if an interferometer builds new stations along its life (like e.g. IOTA), or inserts new ones, or if station names shifts, or changes?

Comment by GillesDuvert - 08 Jan 2014: Yes, I guess we do not need to inforce this complete and fixed list of stations. And keep in mind that station coordinates do change with time... the only pertinent length measurement is the u and v coordinates and at the precision we need you can never get them from star_coordinates+lst_time+station_positions present in the OI-FITS file. You have to read them in the OI_VIS, OI_VIS2, OI_T3 table.

1. To have also the 'equatorial local' coordinate frame possible in OI_ARRAY
2. 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?
3. inserted by GillesDuvert - 08 Jan 2014: For some image reconstruction program (at least WISARD) one needs to treat globally all the closures and V2 obtained at the same time (pseudo-inversion to a set of myopic complex visibilities). One thus has to retrieve the relevant data in OI_VIS2 and OI_T3, sort them to get all the data obtained at the same time, deduce more or less straightforwardly the configuration (2,3,4...n telescopes) based on STA_INDEX values, etc. Future OI-FITS requirement should make sure that one has indeed the same time tagged in OI_VIS2 and OI_T3 for all the relevant set of simultaneous observations, that this time is good enough to unambigously tag a set, that for all closures there are the corresponding V2, and, why not, provide a new table that would link V2 and T3 tables just for this purpose of identifying the 'complete sets' of simultaneous observations.

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 but it is not recommended as it will cause compatibility problems
  • keep the column but set values to NULLS
• Idem for table keywords : Which of them are mandatory or optional (empty string) ?

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.

Comments by JohnYoung - 28 Apr 2011:

There is a subtle difference between the intended purposes of NULL values and the FLAG column to cancel data, which we should have explained more clearly in the paper. The intention was that NULLs be written by the pipeline where the value was not measured or calculated at all. The user should use FLAG to mark (possibly) bad data so they are ignored for model-fitting/imaging; here the values are preserved in the file and can be reinstated if the user changes their mind. I agree that we should explicitly permit NULL for all data types (though for VIS2DATA the row could just be omitted). I am not sure that separate FLAGs are needed for amplitude and phase given the intended usage.

Comment by FlorentinMillour - 26 Jul 2011: There is a reason in e.g. AMBER to store only differential phases and NOT differential visibilities, as the pipeline does not work for the latter. Therefore it would be necessary to separately flag phases and amplitudes in AMBER OI_VIS (which is not possible yet)

Could the VO suggestions below be developed into a list of specific fields which are proposed to be added or changed in OIFITS, with a sentence for each stating what benefit would result (if this is not obvious).

Comments by LaurentBourges - 4 Jan 2011:

• The specification does not define the undefined / unknown value for enumerated values associated to the FRAME keyword and to VELTYP / VELDEF columns. I propose to use the value 'NONE' but an empty string could be also a good choice.
• The OIFits specification does not indicate which FITS optional keywords are mandatory to describe OIFits columns. Indeed, mandatory FITS keywords must be present (TFIELDS / TFORMn) but an OIFits convention should be described for optional keywords. I propose the following convention :
  • TTYPEn : mandatory
  • TUNITn : recommended (the unit is already defined by the specification) for self description and can be useful to other Fits tools.
  • TDIMn : must not be present. This indicates the dimensions of a multi-dimensional array. Sometimes it is present and repeats the TFORMn value : it is meaningless and can lead to reading errors.
  • TSCALn / TZEROn / TNULLn / TDISPn : must not be present (not supported)

Comments by -- GuillaumeMella - 28 Apr 2011: To follow and raise Virtual Observatory effort and practice, we notices following features at JMMC:

• Some additional fields could be dedicated to provide references to reductions software and archive data Ids. This aspect is mainly driven by the Provenance
• Most of data could be associated to data model standards present in the Virtual Observatory to improve interoperability and characterisations.

Specify state of calibration (raw, averaged, calibrated)

OIFITS was originally designed to stored only calibrated, science-ready data. However it is used in several instrumental to also store the intermediated products.

We can introduce a 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.

Comment by FlorentinMillour - 26 Jul 2011: Only "raw" and "calibrated" would be sufficient. I do not think "instantaneous" is necessary as the "time" column already flags time passing.

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.

Comment by JeanBaptisteLeBouquin - 07 Mar 2013: In the PIONIER instrument, the instantaneous visibilities (actually not visibilities but coherent_flux and photometric_flux) are not stored in a FITS file, only the averaged one. Consequently the two following keywords are sufficient: 'RAW' (before calibration of transfer-function) and 'CALIBRATED' (science-ready).

Comment by JeanBaptisteLeBouquin - 07 Mar 2013: At minimum we should specify:

• RAW = do not use for modeling instead you know well the instrument
• CALIBRATED = you can use for modeling

Proposal for correlated flux

Needed for, e.g., model fitting.

Argumentation inserted by JuwePott: VLTI/MIDI data reduction typically produces significantly more precise correlated fluxes than visibilities, since a large fraction of the thermal background photons are uncorrelated. Therefore, it is NOT redundant to save both correlated flux AND visibility in OI-FITS. Furthermore, the phase data reduction steps should be specified to show, if any linear trends have been removed. Therefore, we (Leonard Burtscher, Paul Boley, myself) at MPIA discussed this already a while ago with JohnYoung, and proposed to add the following three fields to the OI_VIS table:

Name	Type	Meaning
PHITYP	STRING	(absolute, 1st derivative, 2nd derivative)
CORRFLX	D (NWAVE)	Correlated flux (Jy)
CORRFLXERR	D (NWAVE)	Error in correlated flux (Jy)

Comment by GillesDuvert: the Jy unit for correlated fluxes above looks good for MIDI and radio interferometers, but photon counts are more useful for optical/nir interferometry. I suggest to use a header keyword FLUXUNIT whose value could be JANSKY, PHOTON_COUNT to precise the unit instead of forcing it.

Comment by FlorentinMillour - 26 Jul 2011: The table OI_VIS is already suited to store correlated fluxes: the column VISAMP could be used for that. Only a keyword in the table header could be added, like e.g. VISTYP="differential" or "correlated flux".

• 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.

Comment from Leonard Burtscher: In MIDI, the exact observable depends on the data reduction method. In EWS, with coherent integration, the observable is really the linear correlated intensity correlated_flux (a complex number correlated_flux, similar than OI_VIS), with MIA, which evaluates the power density, it is the square of this (|correlated_flux|^2 similar than OI_VIS2).

Comment from JeanBaptisteLeBouquin - 07 Mar 2013: We can add the possibility of a unit (e-, ADU, Jy, or ADU^2, Jy^2, e-^2) in the two extensions OI_VIS2 and OI_VIS. If this unit is present and valid, the tables do not contain normalized visibilities but fluxes. Another solution is to create 2 new extension: OI_CORR and OI_CORR2 with similar tables as in OI_VIS and OI_VIS2.

Comment by LeonardBurtscher - 07 Mar 2013:

• @ Florentin -- With MIDI, correlated fluxes have essentially two noise sources: (a) photon noise, (b) uncertainty in the conversion factor (more or less independent of wavelength; shifting the whole spectrum up or down). So, an Nchan*Nchan matrix describing the covariances would be good to catch both. Regarding your proposal to only store visibilities and total fluxes: It would be better to directly store correlated fluxes and total fluxes, since these are the actual measurements.
• @ JB: I would simply keep the field names as they are at the moment (VISAMP/VISPHI) and add a VISTYP keyword like Florentin suggested.

Would this correlated flux extension be used by other people except the MIDI AGN community?

Proposal for OI_FLUX

Proposed by: FlorentinMillour - 26 Jul 2011:

That table could be based on the OI_VIS2 table format, plus a matrix describing the reference pixels if it is a normalized spectrum (in the same way I propose it for differential phases, see above). It would contain following keywords:

Name	Type	Meaning
ARRNAME	STRING	same as oifits 1
INSNAME	STRING	same as oifits1
SPECTYP	STRING	spectrum type, could be "ABSOLUTE" (for absolute flux), or "NORMALIZED"

and the following columns: TARGET_ID, TIME, MJD, INT_TIME, FLAG, same as in OI_VIS. I am wondering if STA_INDEX should be part of this table or not, but in the case it should be, it should be with 1I format (just 1 telescope per spectrum).

Name	Type	Meaning
SPECDATA	D (NWAVE)	spectrum data
SPECERR	D (NWAVE)	spectrum error data

Comments by SylvestreLacour - 2012 Dec 22: I would propose renaming this table OI_FLUX. Since we cannot talk about giving a spectrum (most interferometers now are single mode) but instead of flux as output of the P2VM data-product. For GRAVITY, we are planning to include such a table. The STA_INDEX would then be mandatory, since we are talking about the flux on each telescope. In the header, we would need a keyword "FLUXUNIT" which could be ADU, Jy, Photon, Normalized to one, etc... instead of SPECTYP

Comments by JeanBaptisteLeBouquin - 22 Feb 2013: I vote for OI_FLUX. I like to have the STA_INDEX (one flux per telescope).

Proposal for revision of OI_WAVELENGTH / insName

The insName keywords links the OI_WAVELENGTH table with observations. Generally it is filled with strings like: AMBER, GRAVITY, VEGA... However, the wavelength table of AMBER for instance can be different from one day to the other. If these observations are mixed into the same file, we will have two table with insName=AMBER that are in fact different.

In PIONIER and AMBER, I use a workaround: I include the wavelength range in the name: PIONIER_(1.564,1.896). Hopefully, this string is always different for different spectral resolution or wavelength calibration. However this is a workaround. We can think about a better way to force the unicity of the insName keyword.

Comment by JeanBaptisteLeBouquin - 05 Mar 2013: This seems to be a general issue. Release note of ASPRO2-0.9.4 says "Modified OIFits INSNAME values to have a meaningfull instrument mode description: Instrument_lambdaFirst-lambdaLast-Nch; lambdaFirst, lambdaLast, N are respectively the wavelength of the first and last spectral channels, the number of spectral channels (for example: AMBER_1.48347-2.52552-37ch)"

Comment by GillesDuvert - 30 May 2013: It seems also important that INSNAME should also be IDENTICAL for the data tables that are related: T3 with its VIS2 and VIS, etc. This because utilities will rely on this relationship: myopic deconvolution use T3 and V2, T3 noise is generally correlated with V2 noise (AMBER), OifitsExplorer will need it also, etc... Another way to describe it would be to impose that each INSNAME is really different (different number of channels, of wavelengths) from all the others in the OIFITS file.

Comment by JohnYoung - 31 May 2013: Gilles is correct - the INSNAME is used to lookup the OI_WAVELENGTH table containing the wavelengths at which OI_VIS/OI_VIS2/OI_T3 data were taken. Hence each OI_WAVELENGTH in a file should have a unique INSNAME. Multiple visibility data tables can refer to the same OI_WAVELENGTH.

In general wavelength calibrations vary over time so, for real data, I don't think it makes sense to have a "standard" OI_WAVELENGTH for each instrument configuration. A single file could even contain multiple OI_WAVELENGTH tables for the same nominal instrument configuration, corresponding to calibrations done at different times. Merging several OIFITS into a single file will generally involve changing the INSNAMEs to maintain uniqueness. This is easier if we don't require the INSNAME to be descriptive. For example my oifits-merge just replaces INSNAMEs as necessary with "ins001", "ins002" etc. A separate (VLTI-specific?) header keyword could be added to identify the instrument configuration.

Comment by MichelTallon - 1 June 2013: There is clearly a trend to also use INSNAME to identify the name of the instrument on which the data have been acquired, although the keyword is just needed to identify the OI_WAVELENGTH table. Thus, INSNAME can be changed when data files are merged. Nevertheless, it would be useful to have a way to keep track of the name of the instrument on which the data have been acquired. A keyword could be added (e.g. INSTRUMENT) for this purpose. Perhaps the name "INSNAME" is also ambiguous. Something like "INSLINK" would be more explicit. A keyword pair like INSLINK and INSTRUMENT is perhaps more suitable for wiping any ambiguity out.

Proposal for revision of OI_VIS

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 FlorentinMillour - 26 Jul 2011: A flag matrix could be used for that purpose: it would be a nWlen x nWlen matrix with 1 where the wavelength is used for the reference channel. Tested locally and works fine for all cases.

Proposal for revision of OI_TARGET

Explicit 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...

Comment by JuwePott : what about the origin of the diameters you want to save in the oi-fits? Do they come from a catalog? Typically, diameters are subject to changes (catalog change or new measurement). Therefore, if you want to save diameters, you should also have an entry pointing to the originating catalog, etc... To be quite accurate, adding diameters and there origin, would certainly complicate the OI-FITS. In my opinion, this is secondary information, which should not enter the oi-fits. If you save 'calibrated' visibilities in oi-fits, using certain calibrator diameters, then the diameter uncertainty should be reflected in the visibility uncertainty. Details on the calibration process could be logged in a COMMENT area.

Comment by GillesDuvert : 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.

Proposed by: ChristianHummel - 6 Oct 2010:

I propose to include the following information in the second revision of OI_TARGET: 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?

Comments by JohnMonnier - 2011 Apr 29: I definitely do not support this addition to OIFITS. Requiring users to have a well-tested rapid-rotating code and to worry about all the details of a model is not wise. We should merely include datacube of images for each wavelength. This is pretty much was radio software CASA is now doing and is the most general and straightforward way to discuss calibrators. I do not understand the resistance from some quarters to this suggestion. a Fits image is well established -- only we need to specificy the oriention of the pixels and pixel scale.

Comments by SylvestreLacour - 2012 Dec 22: I agree with John. Why this emphasis on rotating stars? If so, why not YSO too? A fits image seems both more versatile and easier to manage.

Comments by -- JeanBaptisteLeBouquin - 05 Mar 2013: I agree with John.

Proposal for defining FOV

Comments by SylvestreLacour - 2012 Dec 22: On another topic, is there any plan to include FOV of the interferometer? Similar to the lobe-pattern for radio interferometers.

-- JeanBaptisteLeBouquin - 24 Jan 2013: Defining the FOV of an interferometer working after turbulence and partial-AO correction is far from trivial (whatever it is single-mode or multi-mode). Not sure you can even define it quantitatively. You should also remember that the FOV defined by the spectral resolution may be smaller than the telescope lobe. This field of view even depends on the V2 estimator (think about how one can deal with double packet binaries).

SylvestreLacour - 2013 Feb 6: Yes, the seeing is an issue, but hopefully all interferometers will be equipped with an perfect AOs in the future. And it varies with time. The coherence envelope (spectral resolution) also varies with time (depends on the projected baseline) but it can be inferred easily from B and delta lambda. On the other hand, the FOV stays put, and depends only on the FOV of the fiber (or the weighting of the FOV of the detector for multi-mode aperture masking for example).

Proposal for OI_POLARIZATION

Proposed by: SylvestreLacour - 2012 Dec 22:

This proposal is to include the polarisation information of the interferometer. This is something we are currently implementing in GRAVITY to account for the presence of a Wollaston in the beam combiner.

There are two things to do:

1. the coding of Wollaston-split interferometric data in the oifits format.
2. the polarization properties of each interferometric arms.

For the former, I would propose to include the Wollaston-split data inside the NWAVE data array. Than, the user would have to refer to the OI_POLARIZATION array to know which polarization state correspond to which data. Said differently, for data obtained with 10 spectral channel, and 2 polarization states, NWAVE would be equal to 20. The good thing is that it is retro-compatible, since any old software (like MIRA) would simply use both polarization state, without even thinking about polarisation.

For the polarization properties, it has to be included in a separate table, eg, OI_POLARIZATION. At first, we were thinking of basing it on a table like OI_WAVELENGTH. But it would not work, the polarization angle on sky will change with time (as a function of the optical train + field rotators + HWP rotation). So we propose to base OI_POLARIZATION on the OI_VIS table format. As of now, we propose to base the formalism on the Jones Matrix (for those of you who do not know what it is, see a nice tutorial at http://www.utdallas.edu/~cantrell/ee6334/polarization.pdf ). Of course, this is just an idea, you are welcome to comment for a different format. Anyway, we will have four complex values to code for each interferometric arms, each observation, and each NWAVE.

So the table would have the following keywords:

Name	Type	Meaning
OI_REVN	STRING	same as oifits 1
DATA-OBS	STRING	same as oifits1
ARRNAME	STRING	same as oifits 1
INSNAME	STRING	same as oifits1
ORIENTATION	STRING	orientation of the Jones Matrix, could be "NORTH" (for on-sky orientation), or "LABORATORY"
MODEL	STRING	a string keyword that describe the way the Jones matrix is estimated

and the following columns. Most of them are similar to OI_VIS: TARGET_ID, TIME, MJD, INT_TIME, FLAG, STA_INDEX (STA_INDEX define which telescope arm is in question). Visamp and visphi are replaced by

Name	Type	Meaning
TARGET_ID	I (1)	Target number as index into OI_TARGET table
TIME	D (1)	UTC time of observation (s)
MJD	D (1)	Modified Julian Date
INT_TIME	D (1)	Integration time (s)
LXX	Complex (NWAVE)	Complex Jones Matrix value along X axis
LYY	Complex (NWAVE)	Complex Jones Matrix value along Y axis
LXY	Complex (NWAVE)	Complex Jones Matrix transfer between X and Y
LYX	Complex (NWAVE)	Complex Jones Matrix transfer between Y and X
STA_INDEX	I (1)	Station numbers contributing to the data
FLAG	L (NWAVE)	Flag

As an example, for a dataset which consist of 5 spectral channels and the two 2 polarisation states splited by the Wollaston (NWAVE=10), we would have, if the keyword ORIENTATION=LABORATORY:

• LXX=[1,1,1,1,1,0,0,0,0,0]
• LYY=[0,0,0,0,0,1,1,1,1,1]
• LXY=[0,0,0,0,0,0,0,0,0,0]
• LYX=[0,0,0,0,0,0,0,0,0,0]

If the keyword is ORIENTATION=NORTH, we would have:

• LXX=[cos(t),cos(t),cos(t),cos(t),cos(t),0,0,0,0,0]
• LYY=[0,0,0,0,0,cos(t),cos(t),cos(t),cos(t),cos(t)]
• LXY=-[sin(t),sin(t),sin(t),sin(t),sin(t),0,0,0,0,0]
• LYX=[0,0,0,0,0,sin(t),sin(t),sin(t),sin(t),sin(t)]

with t the orientation angle of the Wollaston on the sky.

The MJD column would be used to cross-reference the data with the OI_VIS table.

The good thing is that this nomenclature can include the full polarization properties of the interferometer, necessary if one day we want to do science with the polarization-split information of an interferometer.

Comment by JeanBaptisteLeBouquin - 22 Feb 2013: Why do you want to have TARGET_ID in the table ? MJD is enough to like to the data.

Closures, V2 and Image Reconstruction

We have an image reconstruction program (WISARD) that uses the phase closure (OI_T3's T3PHI,T3PHIERR, U1COORD, U2COORD, V1COORD, V2COORD, TIME, STA_INDEX ) and V2 (OI_VIS2's VIS2DATA, VIS2ERR, UCOORD,VCOORD, TIME, STA_INDEX) information to reconstruct myopic complexes (amplitude, phase). Generally specaking, this kind of program needs to match exactly the data (timestamp, station indexes) between the 2 independent tables OI_VIS2 and OI_T3. We have to define a way to preserve the information that a particular T3PHI at index N in table OI_T3 is the closure of 3 simultaneous observations whose V2 lies at indexes I,J and K in table OI_VIS2. This cannot be done on timestamps and station index entries since (experiences proves) the data providers do not guarantee this correspondence.

List of Persons interested in this discussion.

By adding your WikiName here (see How to Register below) you express interest in participating to a future phone conference on this subject.

GillesDuvert, JohnYoung, JuwePott, ChristianHummel, LaurentBourges, JohnMonnier, LeonardBurtscher, FlorentinMillour, PhilippeBerio, MichelTallon, AntonySchutz, SylvestreLacour, JeanBaptisteLeBouquin, FabienBaron, BrianKloppenborg, EricThiebaut.

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)