MATISSE Simulator User's Guide

Gentlemen and Ladies

Below a description of the Matisse Simulator package intended for the Matisse Science team. The package is written in and requires IDL for operation. The package can be downloaded here: MatisseSimulator download page  
It requires the MIDI Expert Work Station system which can be downloaded here:EWS download page  
A EWS User's Manual is here: EWS: User's Manual  
Image reconstruction requires downloading: MiRA

Walter
29-Oct-2013

CONTENTS:

  1. Introduction
  2. Installation
  3. Inputs
  4. Outputs
  5. Operations
  6. Test Scripts
  7. Cookbook
  8. Input File Descriptions
  9. Output File Descriptions
  10. Calibration
  11. Logging
  12. Options
  13. Principles of Operation
  14. WARNINGS

  1. Introduction:
  2. The Matisse Simulator is primarily intended as a research tool to allow Matisse Science Team members to test whether their projects are feasible, and to optimize the observing parameters. Additionally it may be useful to debug Matisse hardware and software during testing, integration and commissioning. The simulator has three major components:

    1. A sky image simulator. This represents the brightness distribution on the sky either in analytic form or as a series of images in FITS files. This software was written by W. Jaffe within EWS in support of the Scientific Analysis Report
    2. A Matisse instrument simulator. This takes the output of the previous component, computes perfect photometric and interferometric fluxes, and then runs these through a digital version of Matisse to produce simulated Matisse outputs. This is also writen under EWS using data provided by the Performance Analysis Report
    3. An image reconstruction module, based on MiRA. This creates images based on the output of the previous step. This is useful for complicated targets where the scientific result cannot be judged directly from the visibilities. This module was developed by Eric Thiebaut at Lyon and is supported within the Matisse project by Rainer Koehler at MPIA.
    4. For instructions on how to install it and how to use it together with the MATISSE simulator look here:Image Reconstruction with MATISSE


  3. Installation
    1. EWS can be obtained here: EWS download page and instructions for installing it are here:README

    2. The code for the simulator is here: Simulator download page
      This is a tar file. You should create a directory for the simulator, put the tar file there and extract the contents with tar -zxf matisseSim.tar.gz. No further installation steps are needed.

    3. MiRA is a very flexible software for image reconstruction written by Eric Thiebaut c.f. Mira Home

      It is based on a few other packages that you have to install first:
      The installation procedures are described at Rainer Koehler's site

  4. Inputs
  5. The user sees a program mostly in terms of its inputs and outputs (and crashes). Corresponding to the steps just described there are three sets of inputs. These are described in a general way here, with detailed descriptions below.

    1. Sky Image inputs
      These can be of two types, Analytic or Image Files. In the first case a limited number of geometric objects are available (currently only uniform disk "stars"). Their characteristics are described in text files with optional additional files to describe non-thermal spectra. In the second case the user creates externally a set of FITS image files, in one directory, that describe the sky brightness of the target at a number of wavelengths. The directory name and the file naming convention are described to the simulator in a text file. The wavelength and geometric information for the images are provided in their FITS headers.
    2. Instrument inputs
      There are several classes of these:
      1. Instrument Performance Specifications that specify the throughput, resolution, psfs... of various Matisse components as well as atmospheric dispersion tables. These come as IDL .sav files and text files. These should not be altered by the user.
      2. Instrument Setup Tables that specify which gratings, spatial filters etc. you wish to use. These are all text files that can be edited by the user. In the same catagory are tables describing the atmospheric conditions to be simulated, and DRS inputs that describe details of how the output should be handled.
      3. OB tables that describe details of the observing program: which hour angles, DITs, NDITS etc.
      4. Master Table, a text file that specifies which of the various instrument setup files will be used in a given run. This allows the user to prepare (say) different instrument configurations in advance and switch rapidly between them.
    3. Image Reconstruction Inputs

  6. Outputs
  7. The simulator outputs are text files representing logging and diagnostic material and FITS files representing final and optionally intermediate data products. In most cases the FITS headers contain HISTORY records documenting the inputs.

    1. Sky Image Outputs
      By default the analytic models transfer their information directly to the instrument simulation without external outputs. However by specifying the OUTMODEL option in the DRS input file, an OI_VIS FITS file will be produced containing "perfect" visibility data for the target.

      The fitsfile models first generate a 3-d FITS datacube combining all the input images sorted by wavelength. Again if the OUTMODEL option is specified, an model visibility file will be produced.
    2. Instrument Simulator Outputs
      The simulator produces text and FITS file outputs. Three FITS outputs are produced:
      1. OI_VIS This is a FITS file containing several FITS binary tables, described in detail below. The most important of these is the OI_VIS table itself. Depending on the options this contains either visibilities or correlated fluxes+photometric fluxes. There is one table row per OB per baseline (=telescope pair). This all the data for this OB (typically 3-20 minutes)/baseline set, averaged coherently. If no fringeTracker is enabled, this coherent integration will usually be useless.
      2. OI_VIS2. The OI_VIS2 table contains the square of the visibilities (or correlated fluxes), averaged over the OB. Optionally a coherence time can be specified. In this case the visibilities are first averaged coherently over this time interval, then squared, and the squared visibilities averaged over the total OB time. This can be useful if for some reason the detector integration time (DIT) is shorter than the atmospheric coherence time (e.g. in N-band to avoid saturation).
      3. OI_T3.The OI_T3 table contains triple products of the visibilities (correlated fluxes), averaged over the OB. One again a coherence time can be specified.

      The text outputs are logging outputs and crash outputs. The logging outputs are messages that the program things might be interesting to the user. These appear on the screen and optionally in a designated logging file. They also are copied into HISTORY records in the output files. They can be suppressed if they annoy you.
    3. Image Reconstruction Outputs

  8. Operation
  9. Once everything is installed you are ready to go. You should:
    1. Copy and/or edit the Instrument Setup Tables so that the Matisse configuration reflects your experiment. Note that the names of these files are arbitrary and can be changed as long as they are correctly specified in the master table
    2. Copy and/or edit the OB tables to reflect the observing parameters (Hour Angle, DIT, NDIT, telescopes) for your experiment. You will need separate OB tables for LM-band and N-band observations.
    3. Start up EWS by typing MIA (got that?). You either have to be in the directory where MIA+EWS was installed or have that directory in your path.
    4. You should now be inside IDL. Change to the directory where the matisse simulator code was installed:
      cd,'...simulatordirectory..'
      This is not necessary if this directory is in your IDL path.
    5. Type @setup to load and compile the simulator code.
    6. Run one of the test scripts, sit back and watch what happens.
    7. OR: try running the simulator yourself:
      • Create a target object: for an analytic target. This looks like:
        tag='myfirsttest'
        mytarget=obj_new('star', tag, starfile='star.init')

        (More details on starobjects here)

        Alternatively if you wanted to create a target from a set of FITS-files it would look like:
        mytarget=obj_new('modelfiles', tag, modelpattern='testdata/f6*')
             (More details on modelobjects here)
      • Now add an LM-band ObservingBlock description to the target
        mytarget->set,OBfile='oblistLM.star'      (More details on OBfiles here)
        Note that you need separate OBlists for LM- and N-bands (different DITs etc.)
      • Now create a Matisse object: matisse = obj_new('matisse','master.init'),
             (More details on matisseobject here)
             (More details on masterfile here)
      • Now inform matisse about the target: matisse->setObsDef,obsdef=mytarget
      • and tell matisse to process the OBs: matisse->processobs,0
        (the 0 stands for LM-band; 1 for N-band).
        A lot of message should flow by, and a lot of files should be created.
      • To process the N-band observations:
        Assign a new set of OBs to the target (need new DITs,NDITS): mytarget->set,obFile="oblistN.agn"
        Process the N-band observations: matisse->processobs,1
             Currently, separate simulator runs are required for the two bands.

  10. Test Scripts
  11. If you have installed the simulator package you can try running a number of test scripts to see how things go. If you read the scripts, you can gain some insight into the processing.
    1. teststarLM.pro is a script that creates two analytic star targets, one a "Fstar" and one a "bright calibrator". It then "observes" both targets with matisse in a LM configuration (with the LM_MED grating and the ATs in SCI_PHOT mode), records the data into files, calibrates the target visibilities, and the plots the Vis, Vis2 and T3 data.
    2. teststarN.pro runs the same series of observations in the N configuration (N_LOW grating, SCI_PHOT mode, UTs (ATs are too small for this star).
    3. testagnLM.pro runs a similar series of observations, on an agn model consisting of 18 FITS files named testdata/f6....fitsprovided by Marc Schartmann.
    4. testagnN.pro observes the same models in N-band
    To run them
    1. install MIA+EWS and the simulator
    2. starting up EWS/MIA by typing:mia
      If you get "Command not found" you have to either first change directories to the one containing the EWS/MIA installation, or put this directory on you execution path. If this is OK mia should start up.
    3. Change directories to the one containing the matisse simulator code. This can be done inside of mia by just typing: cd,'...directory...'
      This is exactly the same cd command that works in Unix except that you have to type a comma after the cd and you have to put the directory between quotes or double quotes.
    4. Type @setup to load and compile the simulator code
    5. Finally: type:
      @testdata/teststarLM or
      @testdata/teststarN or
      @testdata/testagnLM or
      @testdata/testagnN

    6. Cookbook
    7. This section presents step-by-step instructions to incorporate a model consisting of a set of fits files and operate the simulator. It duplicates to some extent the information in the operations and testscripts sections.
      1. Install MIA+EWS and the Simulator
      2. Create a directory to hold the inputs and outputs. In this cookbook we will refer to this directory as $model. Note that unix environmental variables can be used inside of IDL with the $ sign.
      3. Create your model files at four or more wavelengths and put them in this directory. The names of the model files should be chosen so that they can all be found with a unix-style wildcard description. In the distribution testdata directory, for example, the model files can be selected with the f6__*90.fits specification. The wavelength of each file should be indicated by the keyword LAMBDA =... in the main file header, with the wavelength in meters. The brightness in the files should be in Jy/Pixel. If you really want brightness in other units let me know. Pixel spacing should be specified, in degrees in the CDELT1 and CDELT2 parameters. For historical reasons you can also specify it with a PIXSIZE = keyword but this is a bad idea.
      4. Copy from the installation directory all the *.init files into the $model directory.
      5. Copy from the installation/testdata directory oblistLM.agn and perhaps the file testagnLM.pro. You can rename oblistLM.agn to something you like better.
      6. Now edit the .init files to configure Matisse for your experiment:
        1. You shouldn't alter insspec.init,LMdetector.init,Ndetector.init unless you want to see what happens if you change readout noise, instrument throughput etc.
        2. In ins.init the most obvious things to adjust are the grating name, the polarizers and the photometry mode. You can also set the telescope station names, but you can do this later in the OBlist files.
        3. In atmosphere.init you can change the atmospheric correlation time in the tau0 parameter.
        4. In Ndrs.init and/or LMdrs.init you can alter some options that affect the "postprocessing" of the observation. The important ones are:
          1. tcoherent that specifies the length of coherent preaveraging before incoherent measures (Vis2,T3) are estimated
          2. OUTCORR if you want correlated fluxes instead of visibilities
          3. DEBIAS2 remove noise bias from Vis2 measures.
          4. OUTMODEL output the visibility model calculated before simulating matisse hardware
          5. NONOISE,NOSIGNAL supress noise and signal for diagnostic purposes
        5. Edit the oblist file. Each line represent one OB or exposure. You can specify the hour angle, the dit, the ndit and the telescope station names. If in succeeding lines, the dit,ndit or telescopes do not change, you do not need to respecify them.
        6. Edit the master.init file. In this file you have to specify the names of the other .init files that you use. Remember to include the entire path to the file. In the distribution version of this file you find, for example, inspec = 'inspec.init". For the example here, this should be replaced with inspec = '$model/inspec.init'
      7. Pick a tagname. This will be prefixed to all output file names. For the example here we will use the tag $model/firstrun, which will put the output files in the same directory as the model files.
      8. Change directories to the one that contains the matisse simulator installation.
      9. Start up MIA+EWS by typing: mia. You have to make sure that the directory with the MIA+EWS code is in your UNIX path.
      10. Type: @setup to load and compile the simulator.
      11. You can reference compare the following steps with the test scripts.
        Create a matisse object, specifying the masterfile: matisse=obj_new('matisse','$model/master.init')
      12. Specify the tagname as a character string within IDL: tag = '$model/firstrun'
      13. Specify a search string for the model files: wild='$model/f6_*90.fits' or whatever is appropriate for your files
      14. Now create a "target object" by specifying the model files and the oblist:
        target=obj_new('modelfiles', tag, modelpattern=wild, obfile='$model/oblist.agn',dec=-32.)
      15. Finally: ask matisse to process the observations:
        matisse->processobs,0 (for LM-observations)
        matisse->processobs,1 (for N-band observations)
      The simulator should produce Vis,Vis2 and T3 files containing the simulated raw data.

      You can consider running similar OBs on "calibrator" and trying to calibrate the data.

      You can change some operational parameters on-the-fly so that you can rerun matisse without re-editing all the input files:
      1. tagname: With mytarget->resettag,newtag you can choose a new output tagname for observations of a target object
      2. OB specification If you have defined several different target/OB combinations with targ=obj_new('modelfiles'...) or
        targ=obj_new('star'...), you can attach such a definition to matisse with: matisse->setObsDef,obsdef=targ
      3. DRS options These can be reset with
        matisse->setdrsoptions,LMoptions='...option list '
        matisse->setdrsoptions,Noptions='...option list '
      4. processObs options e.g. matisse->processobs,0,fluxfactor=f, distance=d
        The fluxfactor option simply multiplies the model fluxes by f. This has no effect on visibilities except to alter the signal/noise ratios.
        The distance option moves the target distance by a factor d from that implicit in the original target definition. This can change both the visibilities and the photometric fluxes.

    8. Input Files
      1. Introduction:

        For user inputs, we have in most cases chosen for text file inputs because these are easy to read and edit. There is a separate text file for each major Matisse subsystem; these are listed below:text file descriptions. Each text file consists of a series of lines. Each line begins with: keyword= ... IDL text

        Blank lines are ignored and lines beginning with a semi-colon; are treated as comments.
        The valid keywords are listed in the individual text file descriptions. Keywords are not case sensitive. The IDL text may contain valid IDL statements assigning value(s) to the keyword, including algebraic operators etc. Anything after a semi-colon is treated as comments. For examples see the individual descriptions.

        If the keyword is invalid or there is a syntax error in the statement a message will be printed:
        ..statement.. did not execute and the instrument setup will be aborted.

      2. Sky Image Input Files
        1. Analytic Models

          The only currently available analytical model is STAR that simulates a uniform circular emission disk. You can specify the diameter (millarcsec), position offsets dl and dm w.r.t the delay tracking center (millarcsec), the RA (irrelevant:defaults to 0.) and the declination (important for UV-coverage). You can also specify a name that will be printed in some of the outputs. For the spectrum you have two choices:

          1. Temperature: In this case a black-body spectrum with this temperature will be used. This is an example of an input file in this case. For modelling purposes the bb-spectrum will be computed from 2.8 to 16.8 microns at intervals of 0.2 microns and spline interpolated between these points. If you don't like this you can specify a set of wavelengths with a wavelength FITS file (see next section)

          2. Explicit Spectrum: In this case you have to provide an ASCII text file. Each row in this file should specify a wavelength (microns) and a photometric flux (Jy) at that wavelength. At least four wavelengths are required. The photometric flux at intermediate wavelengths is estimated by spline interpolation. The interferometric fluxes are calculated on the basis of the stellar diameter and UV-coordinates. The name of the this is specified with the fluxfile keyword in the sky image input files. This is an example

        2. Fits File Inputs

          Alternatively, the image input can be specified in a set of FITS image files. Each file must be a two-dimensional image of the sky brightness at one wavelength. The data will be spline-interpolated in wavelength to determine the spectra at the wavelengths that are produced by the specified grating. There must be at least 4 wavelength specifications to allow the interpolation to work, and these wavelengths should span those of the grating. They do not need to be equally spaced.

          All the files must contain the same number of pixels. The wavelength of each image should be specified by a header keyword:
          LAMBDA = ..... / wavelength in meters
          The brightness units should be in Jy/Pixel, i.e. the sum of the pixel values will be the total flux density in Jy. If there is a justified request for another brightness unit (e.g. Jy/steradian) this can be implemented later. The pixel spacing should be specified with the standard FITS keywords:
          CDELT1 = .... (RA spacing in true degrees
          CDELT2 = .... (Dec spacing in degrees)
          You can specify the sky position with the standard keywords:
          CRPIX1 = .... (x-pixel whose position is being specified; 1-relative)
          CRPIX2 = .... (y-pixel whose position is being specified; 1-relative)
          CRVAL1 = .... (RA of this pixel, degrees)
          CRVAL2 = .... (Dec of this pixel, degrees)
          These values can be omitted or, if specified, can be overridden by values of ra and dec when actually running the simulator here.

      3. Matisse Instrument Input Files
        Click on the example links to view an example of each file type. The examples also explain the meaning and choices of the parameters.

        1. Instrument Performance: IP example
          Specification of Matisse performance file, normally users should not change these values.
        2. Instrument Setup: INS example
          Specification of Matisse INS setup for this run:filters, gratings etc.
        3. Detector SpecificationLMdetector example Ndetector example
          You need two of these, one for each detector to specify the detector layout and things like Readout Noise and bias. Normally the user does not need to change anything here.
        4. Atmosphere Specification atmosphere example
          Specify some things like atmospheric temperature, tau0, airmass and location of tables that specify the atmospheric transmission versus wavelength.
        5. DRS Specification LMdrs example  Ndrs example
          You need two of these to specify reduction parameters and options for each detector. The available options are described here
        6. Observation Block (OB) specifications OBlist example
          Specify the characteristics for each OB. Separate OB files must be specified for LM- and N-band observations. These files contain a sequence of lines with comma-separated parameters:the Hour Angle (degrees), DIT (seconds), the NDIT and the telescope stations for this OB. After the first line only the HA is required. If the other parameters are not specified they will be taken over from the preceding line.
        7. Master File Master File example
          Many of the specification input files will not change, while others such as the instrument setup file will change often. To simplify the task of specifying all the files to the simulator, a master file contains the names of all the files to be used in one setup. For the most part then only this file needs to be submitted to the simulator.
      4. Mira Reconstruction Input Files

    9. Output Files
    10. Most of the output files are in variations of the OI_VIS formats which are formally defined here:oirvis definitions.

      Naming conventions:
      When the user submits a set of observation blocks (OBs) to the simulator, he/she has to specify a tag for this run. The tag is a character string, chosen by the user, that is prefixed onto the beginning of all output files for the run. This tag may include a directory specification, in which cases the output will be put into that directory. On Unix systems it is permitted to include environmental variables with $ signs in the tag. Suppose this tag is "../myoutput/AGB1". Then the OI_VIS output from the LM detector will be named:
      ../myoutput/ABG1LMVis.fits and that from the N detector:../myoutput/ABG1NVis.fits

      1. OI_VIS files
        File Name=tag+[LM/N]+Vis.fits
        Suppose a file agn.LMVis.fits has been created. You can read this into EWS with the command:
        agnvis=oirgetvis('agn.LMVis.fits', wave=wave) (the wave part is optional).
        agnvis is an array of idl structures. Each row/element of the array corresponds to one OB/baseline pair. The internal components of agnvis can be listed by typing: help,agnvis,/struct
        For a specific file this description might look like this:
        ** Structure <10b2368>, 13 tags, length=51216, data length=51196, refs=1:
           TARGET_ID       INT       Array[1]
           TIME            DOUBLE    Array[1]
           MJD             DOUBLE    Array[1]
           INT_TIME        FLOAT     Array[1]
           UCOORD          DOUBLE    Array[1]
           VCOORD          DOUBLE    Array[1]
           STA_INDEX       INT       Array[2]
           VISAMP          DOUBLE    Array[1550]
           VISAMPERR       DOUBLE    Array[1550]
           VISPHI          DOUBLE    Array[1550]
           VISPHIERR       DOUBLE    Array[1550]
           FLAG            BYTE      Array[1550]
           FRAME           LONG      Array[1]
        
        The most interesting things here are the obvious UCOORD and VCOORD (meters) and
        • VISAMP = absolute value of complex visibility (or correlated flux) as a function of wavelength
        • VISAMPERR = formal estimate of rms error in VISAMP
        • VISPHI = phase (or correlated flux) in degrees
        • VISPHIERR = formal estimate of rms error in VISPHI
        • STA_INDEX = indices to the telescope station names for this baseline
        Nonstandard features:I have misused some of the possibilities of the OI_VIS formats for special purposes:
        1. Correlated fluxes: If OUTCORR is specified as a DRS option, the recorded VIS data represents correlated fluxes rather than visibilities. These are in various units. For modelVis.fits files they are in Janskys. For LM/NVis.fits files they are in e-/channel. For correlated data they are hopefully in Jy again.
        2. Photometric fluxes: Where SCI_PHOT mode has been specified, and OUTCORR (correlated fluxes) I have stored the photometric fluxes in the same table by indicating that UCOORD and VCOORD are zero. The two entries in STA_INDEX are now the same, indicating which telescope produced the photometric flux.
        3. Frame: This indicates which OB produced these visibilities. The OI_VIS standard does not indicate which measurements were obtained simultaneously and which sequentially. Because it might be interesting to compare simultaneous measurements on different baselines, e.g. to examine closure phases, In theory one could check the TIME entry, but I do not like checking floating point numbers for equality. So I have added the non-standard frame entry to the table.

        Examples of Use
        Plot visibilities in record 5 (0-relative) as a function of wavelength:
        plot,wave,agn[5].visamp
        Calculate and print the projected baseline of each record:
        base = SQRT(agn.ucoord^2+agn.vcoord^2)
        print,base
        Find the photometric records (if any):
        photrecords = WHERE(base EQ 0.)
        Plot the photometric flux of the 2nd photometric record:
        plot,wave,agn[photrecords[1]].visamp
        Note that the 2nd record has an array index of 1 (0-relative).
        Print out all the station names:
        nObs = N_ELEMENTS(agn)  number of OBs
        stationObj = matisse->stations()
        for i=0,nObs-1 do print,i,agn[i].frame,stationObj->stationName(agn[i].sta_index-1)
        
      2. OI_VIS2 files
        File Name=tag+[LM/N]+Vis2.fits
        Suppose a file agn.LMVis2.fits has been created. You can read this into EWS with the command:
        agnvis2=oirgetvis2('agn.LMVis2.fits', wave=wave)
        The individual records in the agnvis2 array look like this:
           TARGET_ID       INT       Array[1]
           TIME            DOUBLE    Array[1]
           MJD             DOUBLE    Array[1]
           INT_TIME        FLOAT     Array[1]
           UCOORD          DOUBLE    Array[1]
           VCOORD          DOUBLE    Array[1]
           STA_INDEX       INT       Array[2]
           VIS2DATA        FLOAT     Array[1550]
           VIS2ERR         FLOAT     Array[1550]
           FLAG            INT       Array[1550]
           FRAME           LONG      Array[1]
        
        Everything is the same as the Vis records except that VIS2DATA contains estimates of the squared visibilities, and VIS2ERR the formal rms uncertainty in the squared visibilities.

      3. OI_T3 files
        File Name=tag+[LM/N]+T3.fits
        Suppose a file agn.LMT3.fits has been created. You can read this into EWS with the command:
        agnt3=oirgetvis3('agn.LMT3.fits', wave=wave)
        The individual records in the agnt3 array look like this:
           TARGET_ID       INT       Array[1]
           TIME            DOUBLE    Array[1]
           MJD             DOUBLE    Array[1]
           INT_TIME        FLOAT     Array[1]
           U1COORD         DOUBLE    Array[1]
           V1COORD         DOUBLE    Array[1]
           U2COORD         DOUBLE    Array[1]
           V2COORD         DOUBLE    Array[1]
           STA_INDEX       INT       Array[3]
           T3AMP           FLOAT     Array[1550]
           T3AMPERR        FLOAT     Array[1550]
           T3PHI           FLOAT     Array[1550]
           T3PHIERR        FLOAT     Array[1550]
           FLAG            INT       Array[1550]
           FRAME           LONG      Array[1]
        
        Each row represents a possible triple product of three visibilities measured on the telescopes specified by STA_INDEX, which now has 3 elements. T3AMP and T3AMPERR are the amplitude and its standard deviation of the product, while T3PHI and T3PHIERR are the (closure) phase.

      4. Detector Image files NYI (= Not Yet Implemented)


    11. Calibration
    12. There is currently a very limited calibration facility within the simulator.
      If you have run the simulator on both your target and a "calibrator" target (a small bright star), you can try typing:
      1. CalibrateVis, targetTag, calibratorTag, band
      2. CalibrateVis2, targetTag, calibratorTag, band
      3. CalibrateT3, targetTag, calibratorTag, band
      where band is 0 or 1 for LM- and N-bands. This currently only works for data taken in SCI_PHOT/VISIBILITY modes and the outputs are "calibrated visibilities" in files named tag.[LM/N]CalVis.fits etc.

    13. Logging Options
    14. The matisse simulator can direct its text output to any/all of three locations:
      1. The terminal screen
        By default this is turned on when you create a matisse object
        If you want to supress terminal log output type:
        matisseObj->resetLog,term=0 where "matisseObj" is whatever you have named the matisse object,
        Turning the terminal back on:
        matisseObj->resetLog,term=1
      2. A logging file
        You can direct a copy of the same information to a arbitrary file. You can do this when you create the matisse object:
        myMatisse=obj_new(masterfile, logfile=logfilename)
        or at a latter time:
        myMatisse->resetLog,logfile=logfilename
        This example also works to close an existing logfile and switch to a new one.
        To just close without opening a new file:
        myMatisse->resetLog,logfile=''
      3. A history file
        Yet another copy of the log is kept in a temporary History file in the /tmp directory. When you create output FITS files, this information is dumped into the FITS header as HISTORY records. Then the current history file is closed an a new one opened. You can artificially force the creation of a new history file with:
        myMatisse->resetLog,/history

    15. Options
    16. The most useful options are those affecting the outputs of the simulator. These are specified in the DRS specification files, separately for the LM and N simulations. They can also be on-the-fly with the setDrsOptionscommand.

      In the setup files, you specify them by adding an options line to to the file, e.g.
      options='OUTCORR NONOISE'
      This will produce correlated fluxes (not visibilities) without any read-out our photon noise. Currently the available options are: The right side of the option line is a character string, between '' or "" signs. The various options are concatenated and blank separated.

      An additionl drs option is
      tcoherent=...
      This specifies whether detector frames should be averaged coherently for a given time interval before producing the incoherent measures Vis2 and T3.

    17. Principles of Operation

    18. WARNINGS and BUGS
    19. The current release is definitely not complete and buggy.
      A few of the worst problems:

    Table-of-Contents