(r50) OIFITSTwoProject < Jmmc

Tags: view all tags
---+ This page is intended for discussions on the draft: Second Version of the _[[http://www.mrao.cam.ac.uk/research/OAS/oi_data/oifits.html][%RED% OI-FITS %ENDCOLOR% format]]_

-------------------------------------------

---+ The Document in its current state:
 [[http://www.jmmc.fr/twiki/pub/Jmmc/OIFITSTwoProject/oifits_norm_v2.pdf][Draft for version 2 available here:]] http://www.jmmc.fr/twiki/pub/Jmmc/OIFITSTwoProject/oifits_norm_v2.pdf!*


---+ The historical discussion on this format is here http://www.jmmc.fr/twiki/bin/view/Jmmc/JmmcOldPageOnOifitsTwoProject

---+ This page is free for your comments. 
   1 You may need to register to enter coments. 
   1 Do not forget to sign them using the signature button!

---++ Comment by !MikeIreland

As discussed at the Interferometry Forum, covariance between visibility and closure-phase points as a function of wavelength is *essential*. This can be included 
with the following:

In OI_VIS2

   * VIS2COV  D(NWAVE,NWAVE)  (optional) Covariance matrix of squared visibility.

In OI_T3

   * T3AMPCOV D(NWAVE,NWAVE)  (optional) Covariance matrix of triple product amplitude
   * T3PHICOV D(NWAVE,NWAVE)  (optional) Covariance matrix of triple product phase

Implementing the full wavelength and observation covariance matrix is possibly tricky, but would be required for me to e.g. put aperture masking data in oifits.
The most general way to implement this would be:

In OI_VIS2

   * VIS2IX I(NWAVE) (optional) Index of the V2 point.

In OI_T3

   * T3AMPIX I(NWAVE)
   * T3PHIIX I(NWAVE)

In a separate table OI_EXTRACOV:

   *  ... firstly requires a title...
   *  INDICES I(NIX)     The indices from the various VIS2IX, T3AMPIX, T3PHIIX tables that are used in this covariance matrix
   *  COV D(NIX,NIX) Full covariance matrix of the quantities indexed by INDICES.

This would enable e.g. the covariance between OI_T3(T3AMP) and OI_VIS2(VIS2DATA) to be stored. By convention, I suggest that these covariances are added to 
any covariances already stored in OI_VIS2 and OI_T3. This would enable e.g. temporal covariances due to common calibrators to be easily recorded and could help
to avoid unwieldy oifits files that have a giant N_OBSERVABLES * N_OBSERVABLES matrix in them.

Note that the VISCOVRI as described in the OIVIS format should have D(NWAVE) not D(NWAVE,NWAVE), with each element being the off-diagonal element of a 2x2 covariance matrix between the real and imaginary parts.

---++ Comment by !AntoineMerand

   * Visibility and correlated flux: do I understand correctly that UNITS (table 1) apply to all data of the HDU? if so, can you handle one OI_VIS holding visibilities and the correlated fluxes? If I understand well, you cannot, so you need 2 distinct OI_VIS tables. In practice, it should be easy since I expect instruments providing correlated fluxes in OI_VIS, and visibilities in OI_VIS2 (no OI_VIS). Maybe would be worth to detail how correlated fluxes should be stored.

   * MP and MB: "Ratio of input over output apertures&#8221; and "time-varying component of the IFOV&#8221;. I agree with Gilles, MB should not be in the table, or only optional. Do we have existing or plan instruments with such feature?

   * concerning OI_WAVELENGTH: 
      * why should we have EFF_BAND set to NULL in the case monochromatic values? I think there should always be a EFF_BAND, I cannot think of a realistic monochromatic case&#8230;  
      * "These estimates should include the effect of the earth&#8217;s atmosphere, but not the spectrum of the target (the effect 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).&#8221; what does that mean? do yo mean that if the target is red/blue shifted, the wavelength should not be in the rest referential of the target?

   * for differential quantities in OI_VIS: "VISREFMAP must be present if any of VISTYP or PHITYP is "differential". If VISREFMAP is absent, neither can be differential.&#8221;: isn&#8217;t this too strict? Same could be said in the case visibility (or vis2) are binned.

   * concerning OI_SPECTRUM: 
      * should be restricted to spectra derived with the interferometric instrument, not to third party instruments! otherwise, why not have an OI_PHOTOMETRY as well? Few interferometric instruments are suitable to extract photometry, but MIDI for instance, is pretty good at it&#8230; 
      * I do not understand the meaning of &#8220;CALIBRATED&#8221;: I think the relevant information should be: is it raw, normalized, photometrically calibrated? Another important information is wether or not the telluric lines were removed. 
      * I do not understand either the usefulness of the following: "If the boolean keyword header CALIBRATED is FALSE, the STA_INDEX column must be present, and the flux stored in FLUXDATA is the flux measured on the telescope indicated by STA_INDEX."

   * some things not covered by the document:
      * Astrometry: GRAVITY will not be able to save its reduce data in the OIFITS format. I am not sure it is really possible, but maybe there should be a foreword stating that astrometry has been excluded.
      * Error correlations due to common calibrators for OI_VIS2. Each calibrated observation should give the name of the 2 calibrators used for calibration, as well as their visibilities. See http://www.aanda.org/articles/aa/pdf/2003/12/aa2990.pdf for a description of how correlations can be used. 


---++ Comment by Main.PierreCruzalebes
Dear colleagues,
Since optical long-baseline interferometric data can be processed using the instantaneous spectral distribution of the complex triple product, as is it done for instance with the SPIDAST software, I suggest to add to the OI_T3 data table the real and imaginary parts of the triple product with their errors.
Staying at your disposal, with my best regards.
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
pdf	oifits_norm_v2.pdf	r2 r1	manage	144.4 K	2014-05-20 - 08:25	GillesDuvert
Topic revision: r50 - 2014-06-29 - MikeIreland