The operation of VEGA/CHARA : from the scientific idea to the final products

An interferometric program relies on an interferometric infrastructure and on one or many instruments. VEGA operates either with $2$, $3$ or $4$ telescopes depending on the science objectives. In all these modes, the choice of the telescopes among the $6$ that CHARA is operating opens a large number of possibilities. It’s clear that, starting with a scientific idea, the problem of defining the best observing strategy is not obvious and needs tools. This is usually done by community softwares that simulate the interferometer. Moreover, doing the observations and optimizing the night with the different programs, is also a complicated task. In order to facilitate these two main aspects of the VEGA operation, we have developed a global vision of the information and data flow, starting from the scientific idea up to the final data.

This paper aims to present the different steps of the VEGA use. We present the VEGA instrument and its main science programs in Section 2. Then Section 3 presents the preparation phase, Section 4 details the way the observations are conducted and finally Section 5 presents the necessary steps from the raw data to the final products. These steps are schematically summarized in Fig. 1 where the relations between all the software tools and the databases are presented.

The Center for High Angular resolution Astronomy (CHARA) of the Georgia State University operates an optical interferometric array located at the Mount Wilson Observatory that consists of six one-meter telescopes placed in pairs along the arms of a Y-shaped array. It yields $15$ baselines ranging from $34$ to $331$ m. Operating in the near-infrared with CLASSIC [Sturmann et al., 2003], CLIMB [ten Brummelaar et al., 2012], FLUOR [Coudé du Foresto et al., 2003], and MIRC [Monnier et al., 2004], and in the visible with PAVO [Ireland et al., 2008] and VEGA [Mourard et al., 2009], the CHARA array allows a maximum angular resolution of $1.3$ and $0.3$ millisecond of arc in the K and V band, respectively.

The spectrograph is designed to sample the visible band from $450$ to $850$nm and benefits from three spectral resolutions, although the lowest one is no more used because of the difficulty of getting an accurate enough group delay tracking. It is equipped with two photon counting detectors looking at two different spectral bands. The main characteristics are summarized in Tab. 1. The simultaneous operation of the two detectors is only possible in high and medium spectral resolution. For instance, the optical design allows simultaneous recording of data (in medium spectral resolution) of the spectral region around $H_{\alpha}$ with the red detector and around $H_{\beta}$ with the blue detector. Observing in the blue requires good seeing conditions but increases by $30\%$ the limit of spatial resolution of the instrument with respect to its operation around $700$nm. The limiting magnitudes of VEGA/CHARA are presented in Tab. 2. They of course highly depend on the actual seeing conditions and of the intrinsic target visibility.

The medium ($R\simeq 6000$) and high ($R\simeq 30000$) spectral resolutions are well suited to perform a wavelength analysis of the interferometric signal (visibility and phase), providing a kinematical resolution of $60$ and $10$ km s^-1, respectively. It allows to probe efficiently the radiative winds and fast rotating photospheres of hot Be stars (Delaa et al. [2011]; Meilland et al. [2011]), the complex structure of interactive binaries Bonneau et al. [2011], the disk of young stellar objects Perraut et al. [2010] and for instance the the chromosphere of K giants Berio et al. [2011]. The medium resolution is also well suited for absolute visibility studies in order to determine very precise angular diameters or to determine the orbit of detached binaries or multiple systems. Recent results of such programs concern the study of roAp stars Perraut et al. [2011] or CoRoT targets Bigot et al. [2011] and more recently exoplanet hosts stars Ligi et al. [2012].

Another interesting possibility is the presence of a polarimeter that could be inserted into the beam. This gives new insight into many physical processes. Many science sources are linearly polarized, in particular at a small angular scale, and the interferometric polarized signal is a powerful probe of circumstellar scattering environments that contain ionized gas or dust Elias et al. [2008]; Ireland et al. [2005]; Chesneau et al. [2003] and of magnetic properties Rousselet-Perraut et al. [2000, 2004].

In this paper we do not address the important question of the best choice of the interferometric baseline and observing strategy for a dedicated science program. This has been already described in different summer schools papers or textbooks (see for example Labeyrie et al. [2006] and references therein). This is usually based on online software simulating the answer of an interferometer to a specific object, described either by a toy model (uniform disk, gaussian disk, elongated disk, any combination of geometric bricks…) or by fits images of brightness distribution. These softwares estimates the 2D fourier transform of the brightness distribution at the spatial frequencies sampled by the interferometric configuration (baselines, wavelength, target coordinates, time, instrumental configuration). This simulated data could then be used to estimate if the parameters of the initial model or if an image of the object could be well constrained by the specific configuration. With this in hands, an observing idea could be turned into a serie of instrumental configurations.

The VEGA instrument, as any other beam combiner, requires a careful preparation. Whatever the mode of observation, on site or remotely, the procedure is basically the same and first based on a specific dedicated software, called PIVOT¹¹1http://pivot-ws.oca.eu/ (Prototype of Interferometric VO Tool) developed by Observatoire de la Côte d’Azur (OCA). The VEGA instrument has indeed a multi-program strategy of observation. Every night is optimized to perform the maximum of observations (of different targets), but with the minimum of configuration changes. In this context, the PIVOT software is extremely useful to gather and manage all observing programs, with respect to their own priority targets and configurations. PIVOT uses the Virtual Observatory technique and several databases, like Axis2, Java, SAMP, XML and MySql [Mourard et al., 2012].

The ultimate aim of the PIVOT software is to help the PI of an observing program to prepare an ASCII file (called a starlist) containing all the information needed (for VEGA and CHARA settings) to perform a certain program Mourard et al. [2011]. It contains all the observing blocks including the spectral calibration ones. Different classes of users have been defined, and the access is specific for each one of these classes : the PI of the VEGA instrument, the PI of run (which means the person in charge of the organization of a series of observing nights with VEGA), the PI of night (i.e. the observer), and the astronomer (PI of the scientific program). The procedure is the following.

First, the PI of an observing program fills one or more PIVOT proposals, each consisting in as many entries as science target or different instrumental configurations. It means, he has to enter (1) the names of the stars to be observed, (2) the telescopes and baselines to be considered, (3) the duration of the observation, and (4) the spectral configuration. Several tools can be used for that (see below). PIVOT gets the stellar fundamental parameters (HD number, magnitudes, coordinates…) in the CDS-ADS²²2http://cdsweb.u-strasbg.fr/ database, which hosts the SIMBAD and Vizier tools. They contain a very large and complete database of astronomical objects and astronomical catalogues and tables, respectively. As already said, one PIVOT entry corresponds to a star with a given configuration.

When all proposals are entered, the PI of the VEGA run has access to all the different configuration requests and make a classification and sorting of all the PIVOT entries. The PI takes into account the ranking from the Time Allocation Committee of CHARA and the internal VEGA classification of priorities. Using this information and the initial preparations made by the different programs, the PI is able to identify a small number of configurations able to accommodate all the priorities. He could also ask to some of the programs to change their initial request of baseline in order to simplify the global organization of the runs. For each configuration, he defines a template, associating each requested telescope to a POP and a beam. This is done taking into consideration the position of the CHARA pupils as seen by the VEGA instrument. Indeed, PIVOT provides for each telescope the predicted position of the pupil image according to the position of the cart of the delay line : the position of the pupil has to be the closest to zero which means that the distance between the pupil and the sky pupil position is minimized. If, for a given night, too many different configurations are required, a choice has to be made among them to reduce the number of configurations per night in order to save time. Fig. 2 presents a typical plot for a 4 telescope configuration.

The choice of POPs (Part Of Path, i.e. static additional optical paths) and beams is highly connected to the observability of all the targets to be observed in a given night. To check the observability of the stars, which means that the star elevation is higher than $30^{\circ}$ and that the optical paths could be equalized within the strokes of the delay lines, PIVOT and Aspro$2$³³3http://www.jmmc.fr/aspro page.htm exchanges data through inter operability protocols. Aspro$2$ is a tool developed by JMMC to estimate the observability of stars and to calculate visibility map of associated toy models. There is an important choice of instruments and facilities available : VEGA/CHARA, MIRC/CHARA, PIONIER/VLTI, AMBER/VLTI, PAVO/SUSI, … For each instrument, all available configurations of telescopes are taken into account. Moreover, the stars parameters are extracted with an interoperability mode between Aspro$2$ and SIMBAD. Such interoperability modes (between SIMBAD, Aspro$2$ and PIVOT) are based on the SAMP messaging protocol which uses VOTable format (XML) file, both being Virtual Observatory (VO) standards provided by the Virtual Observatory Alliance (IVOA⁴⁴4http://ivoa.net/).

The PI of run is supposed to check the observability in its globality (i.e. for all stars together). Indeed, in principle, the POPs can be changed in a given night of observation (not the beams), but the PI of run try to reduce such changes (which require $10$ min of time) as much as possible to keep the same POP configuration, but of course, it can reduce the observability of certain targets. A compromise has to be found and the web-based tools help to take decisions on this.

Once the proposals are approved by the PI of run, the PI of program has to create the starlist file with the help again of Aspro$2$. This procedure is very easy thanks to the interoperability of several tools. First, each proposal is sent (individually) to Aspro$2$ via the interoperability mode. Then, the information are sent by Aspro$2$ to SearchCal⁵⁵5http://www.jmmc.fr/searchcal [Bonneau et al., 2006]. SearchCal, also developed at JMMC, collects all the calibrators from different catalogues, and sort them out according to the given limitations (e.g. in magnitude, coordinates, diameter…). The best calibrators found can then be sent again to Aspro$2$ to check their observability (as the calibrator is closed to the target in sky in principle, its observability is generally good, but this has to be verified) and linked them to the target. Finally, the whole set (target+calibrators) is sent back to PIVOT. An edition tool inserted into PIVOT permits correction and completion of the starlist file, for example for the number of observing blocks requested (duration of observation) and modify other parameters (recording with CLIMB, wavelength, spectral resolution, etc.). Once done, the starlist file is generated and is associated to the corresponding proposal. It also can be stored as an ascii file.

Finally, the PI of night (i.e. the observer) can prepare if necessary the strategy of observation all over the night using a specific panel in PIVOT. This step is required when the strategy over the night is particularly complex (observation of different stars at different angular hours, etc), selection of calibrators… For this purpose, the target and calibrators are selected (for each program), and the observing time is plotted as lines for each different star, the length of the segments being proportional to the duration of the observation. The strategy of observation is thus more visible and it becomes easier to organize the set of stars to observe during each night.

Before the VEGA observations, the PI of the run is supposed to ($1$) define the teams of observers for all the VEGA run (in general two persons for three or four consecutive nights), ($2$) send an e-mail to the CHARA team ($48$h before the beginning of observations) specifying the configurations used (telescopes, POPs, beams, and the need or not of using CLIMB as a fringe tracker), ($3$) verify the starlist files (using a dedicated script) and put them in a specific folder on the VEGA control system, ($4$) provide to the observers the list of targets to be observed with the corresponding strategies of observations (the number and the sequence of measurements) together with the priorities in terms of targets and configurations (which depends also on the quality of the night). The preparation of the VEGA instrument itself is however done by the PI of VEGA or by a person in charge of these technical aspects (chiller, cooling of camera, etc.).

During the observations different tasks have to be done: instrument checking and setting, recording, coordination with the CHARA operator, log files, control of observing conditions (weather, humidity, observability, …), decision on programs…

The VEGA observer has remotely access to four VEGA computers located in the electronic cabinet situated on site : the central computer controlling all the VEGA motors, the computer for the tracking of fringes, and the computers of the ‘blue’ and ‘red’ cameras, respectively. The connection to these computers has to be checked (in particular in remote) and several applications have to be launched at the beginning of the night. Operating the instrument is done using different Graphical User Interfaces talking through the internet to the different low level servers of VEGA of CHARA.

The sequence of observations is the following. The observer chooses a starlist file and inside this starlist file one of the observing block. During the slewing of the telescopes and delay lines, the setting of the VEGA instrument is done (wavelength of reference, spectral resolution, camera used, etc.). This only requires a few minutes. As soon as the first star light is locked by the CHARA tip-tilt, the VEGA instrument performs fine tuning of the alignments by controlling the position of the pupils at the entrance of the spectrograph and the correct centering of the star images on the spectrograph slit. These optimizations are done for each beam by moving remotely the corresponding M$10$ mirrors and the tip/tilt feeding mirror.

An unique capability of the CHARA array is to allow simultaneous observations with two different combiners. We thus generally use CLIMB as an external group delay tracker. As it is operating in the infrared, the visibility contrast is in principle larger than in the optical which allows to find and track fringes more easily. When CLIMB is aligned and has found the fringes offsets, a delicate operation begins in which VEGA has to be cophased with CLIMB. This is done by moving the CLIMB feeding mirrors and compensating these internal delays by moving oppositely the delay lines. In average, $30$ minutes are necessary to perform this step at the beginning of the night or after each triplet change. When cophased, VEGA can record the data.

During the recording, one has to fill the log of observation with several information, such as the PI of the program, the observed targets (and calibrators), the time of recording (beginning and end), and any specific quick comments that could help the data reduction process (quality of the fringes, loss of the star light, seeing, etc.). At the end of a sequence of observations (calibrator-target-calibrator) a spectral calibration is required which corresponds to a specific entry in the starlist file.

At the end of the night, the recorded data are archived and pre-processed automatically: several backups and also a preliminary data reduction are done. For that, the observers have to verify the consistency of their data (several folders and files are indeed generated) and send a script. The VEGA database is also automatically filled with metadata information. The database information and the logfile of the different nights permit to check the overall progress of the execution of the observations, either for an individual program in terms of number of measurement’s points or for the correct execution of the top priority programs. Again at this level the decisions are taken with respect to the global ranking of the programs that the Time Allocation Committee of CHARA and that the team of VEGA co-Investigators have made initially.

The OCA has developed a data reduction software (vegadrs) to process the data obtained with VEGA. It is installed both at Mount Wilson and Nice. The VEGA data processing consists of several steps. First, the raw data is converted and a spectral calibration is done. An initial processing is done to check the data quality and eventually reject short sequences of bad data. During this step, one can choose the detector (blue or red) to be considered, and one can also visualize the corresponding spectrum to check for instance the presence of spectral lines in absorption or in emission and thus decide of the processing strategy. The continuum spectrum is flattened and calibrated (polynomial laws), and the width of the spectral band (for the data reduction) is defined. Several scenarii of processing are available. The autocorrelation processes the spectral density over one spectral band, whereas the cross correlation performs a cross-spectral density between two spectral bands. In both cases, the processing is done and a sum is performed over the individual files or blocks (each block contains in principle $2500$ individual frames of 10ms). In the so-called temporal mode, the processing is performed on each block not as a whole but on a series of a certain number of frames. This mode is recommended only if the data are of good quality.

After this, a configuration file is store and the whole processing sequence is generated as a shell script. After the processing itself, one can visualize the results with a graphical user interface that shows the fringe signal for each block and the corresponding raw visibility, the optical path difference (OPD) and the Signal to Noise ratio (S/N). Fig. 3 presents a typical plot of an observing sequence.

It is then possible to remove the blocks of bad quality if one considers that they are damaged by instrumental or seeing conditions. When done, the results are finally ready to be analyzed. Using different IDL programs, raw and calibrated visibilities are estimated taking into account the selected calibrators. The final output is an oifits file containing the calibrated visibilities of the science star that can be read for example by the LITpro software. These oifits files are stored in the central VEGA database.

The LITpro⁶⁶6http://www.jmmc.fr/litpro (for Lyon Interferometric Tool prototype) software [Tallon-Bosc et al., 2008] has been developed by JMMC and aims at fitting models on data obtained from optical interferometers. It assumes that the direct model of the data to be fitted is known. Thus, many models are available, like uniform disk, linear limb darkened disk, ring, flatten ring, gaussian…that are all combinable together to build more complex shapes. The user loads the oifits files on the software, and chooses the model and the type of data to be fitted (squared visibility, modulus of visibility, phase, Spectral Energy Distribution…). According to the selected model, various free parameters can be fixed. The output corresponds to the free parameters, along with the reduced $\chi^{2}$, standard deviations, covariance and correlation matrices. The software also provides graphical tools to visualize data, models, residuals, cuts in the $\chi^{2}$ space, etc.

The JMMC has also developed an oifits database in order to share the files made by the interferometric community. This tool is useful as is allows to use real or simulated data to perform modeling. Finally, after publications, some editors are requesting to publicly share the fits files associated with the observations. For some of our data published in A&A, this is already done through the CDS.

In this paper we have described the sequence of actions one has to do to proceed from an interesting scientific idea using high angular resolution up to the resolution of the question with data and comparison with models. Due to the intrinsic complexity of the interferometric measurements, mainly due to the possible large number of observing modes, it has been of utmost importance, for non specialists, to highly simplify the procedure. This was exactly the aim of the work we have developed in the last years and the fact that, now, non-interferometric astronomers are already using VEGA for their scientific programs is certainly a great step forward. Thanks to the development of interoperability by the JMMC and OCA teams, in the framework of the development of the Virtual Observatory principles, it has been possible to easily link the different applications and to use the powerful capabilities of databases to smooth all the interferometric process.