Software

The GIANO software is foreseen to run on a dedicated PC-Linux based workstation. This choice is considered robust and reliable compared to other existing PC operating systems. In particular, the use of Linux kernel 2.6 ensures some advantages in terms of general performances, software improvements, networking and system security.
At the highest level the GIANO software include the GIANO Control Manager (GCM), which coordinates the top-level sub-systems and related functions, namely the instrument control software (ICS), the observation software (OS) which pilots two main moduli, namely the Detector Control software (DCS) and the Observing Blocks/Templates (OB), the data reduction software (DRS) and the telescope interfaces.

Image GianoSW
Schematic representation of the GIANO software architecture.

Each sub-system is devoted to a particular job, it is independent from the others and foresees a GUI written in Tcl/Tk (and useful extensions like incr Tcl). The advantage of this modular structure implies both reduced software complexity and easier maintenance. All the inter-process communications are implemented by means of Unix-like sockets. The communication protocol has been designed to be as uniform as possible along all channels and consists of packets which are composed by a header containing essential information, among which the "magic number", a destination address, the packet description and reference number, a validity check and the related packet length. All data are in plain ASCII for easy of debugging and maintenance.

Instrument Control Software

As a middle-ware between the hardware and the scientific functions, the ICS is in charge of collecting and recording instrument status data, forwarding movements and setting commands, and synchronizing the operational flow. The management of all GIANO sensors and controls of the mechanical movements are a crucial point that must be handled by dedicated functions called Instrument Status (IS). The monitoring of all these parameters are foreseen to be done by means of 3 separated processes that must always run in background on the GIANO PC-Linux system. These tasks can be summarized as follows:

The more practical solution to build each IS block is to use a socket transmission protocol between the PC and the related hardware controller. In case of serial controllers it is possible to use a "serial-Ethernet" transceiver like e.g. the commercial Lantronix multi-port devices. Each IS input/output command is driven and addressed to a specific IP number (one for each sub-system).

The spectrometer is equipped with many sensors positioned throughout the cryostat to monitor the temporal and spatial variation of the temperature during the instrument cooling/warming processes and during normal operations. These are commercial temperature sensors (PT100) and controllers (Lakeshore) which communicate directly with the PC-control system using their dedicated serial protocol. To minimize electronic drifts and long term spurious effects on the images, the array temperature should be thermostatically controlled to pre-selectable value within a few 0.01 K. This can be readily achieved using a commercial system (Lakeshore) which include temperature sensor, heater and controllers which can receive commands and transmit telemetric information through a standard serial protocol. These serial communications are re-routed on the ethernet by a commercial (Lantronix) terminal server.

The temperature and pressure monitor program (IS1) reads every few seconds the temperatures of all sensors inside the cryostat and the dewar pressures. Higher reading frequencies are not necessary as the thermal time constants of GIANO are expected to be of the order of hours.

The continuous monitoring and storage of temperature and pressure values are mandatory in order to perform the initialization of the GIANO control system. For this reason the IS1 background process (at the highest priority) must be always running. IS1 has a startup procedure which senses the environment and acts accordingly. Obviously, there can not be two IS1 processes running at the same time, hence if a previous IS1 process is running, the second IS1 kills itself.
IS1 performs sensors initialization, prints out the values and installs itself as a background daemon. All sensor values read by IS1 are sent immediately to the GIANO Maintenance Archive by the ICS. If the link to the database is not active/available the values are stored into a local log file and sent to the database as soon as the communication channel is ready.

For IS2 (cold movements) and IS3 (warm movements) a similar scheme is foreseen. Both daemons monitor continuously the instrument status and communicate all data to the ICS. IS2 and IS3 can receive movement commands and transform them into elementary instructions to be executed by the motor controllers. Both motor daemons follow the same startup procedure of IS1. IS2 and IS3 provide an on-line status of all motors, and communication of these parameters run in both directions (client-server system-like).

The ICS includes a main graphical User interface (GUI). This is a stand-alone panel mainly used for test and maintenance purposes. Its basic functionality can be summarized as follows:

Observation Software

The OS controls all the parameters needed to perform an acquisition: pointing coordinates, instrument and calibration units initialization and set-up through the ICS, array set-up and exposure time count-down through the DCS. The setting of the parameters occurs through a suitable GUI and additional frame processing facilities for quick look purposes are also foreseen.

In order to view all acquired frames we adopted DS9 as the standard real-time and quick-look display for GIANO. SAOImage DS9 (http://hea-www.harvard.edu/RD/ds9/) is a Tcl/Tk GUI with a powerful image display widget, integrating a number of popular libraries for world coordinate system computations, remote image access via HTTP, and other features. This package is commonly used by astronomers to view/handle fits files.
In particular, SAOImage XPA messaging system provides an easy communication between DS9 and other Unix/Linux tasks, including X programs and a few scripting languages. It also provides an easy way for users to communicate with DS9 by executing XPA client commands in the shell or by using such commands in scripts. Because XPA works at the programming as well as shell levels, it is a powerful tool to interface different environment packages.
The GIANO OS GUI contains an embedded DS9 panel which is configured to display automatically the acquired frame at the end of each exposure. To avoid undesirable activities (i.e. off line data reduction) the user can only perform a few basic actions: set the zoom, change scale and color display, enable horizontal/vertical cut graph. Manual loading of fits files is disabled.
The GIANO Imaging mode is available only for the centering of an astronomical object in the slit. To allow this operation a direct interface between the embedded DS9 and IRAF (http://iraf.noao.edu/) has been added. To center the star the user can choose either daoedit} or imexam tasks. Using the cursor keys it is possible to estimate the center of a displayed object, plot the radial or the surface profile, get some essential statistical parameters. We have adopted the standard graphic interface provided by IRAF.

Observing Blocks

All the necessary parameters for the instrument set-up, target acquisition and guiding, and exposure execution can be provided using suitable observing blocks and instrument templates which can be compiled off-line during the phase I and phase II preparation. Additional tools like the Exposure Time Calculator (ETC) are also foreseen.

Detector Control Software

The DCs manages the spectrometer array controllers. The DCS consists of two different parts: the first resides inside the PC-Linux and the second runs on the embedded processor at the focal plane electronics and has direct access to the hardware and it is responsible for the initial handling of raw data in real time.
The two branches are interfaced by means of a standard Ethernet connection, on which data and commands are sent to Unix-like sockets. The software portion inside the embedded processor manages the section of the appropriate waveform for the detector, controls the data flow and can handle special observing modes such as multiple starts and stops.
More specifically, it can perform any of the following tasks:

Data Reduction Software

Programming Language and environment

The GIANO Data Reduction Software (hereafter DrG) has be designed to run on different Unix/Linux platforms and relies on utilities available under the Unix public domain software. All data flow will be through FITS and ASCII formats. The DrG back end will be entirely written in C99; the front end will be developed in C99 using Gnu GTK libraries and, at some stage, with the popular DS9 display program via XPA access point. We also plan to release a command-line version working in unattended automatic mode.
The DrG package will be provided with makefiles generated by Gnu automake and a configure script generated by Gnu autoconf.
A small number of external libraries will be needed:

DrG back end

GIANO is an instrument with very few observing modes, each of them producing a quite constant and repeatable distribution of light on the array. This allows us to develop a highly optimized code: 2 main setup will be available for the high and low resolution, respectively.

The DrG modules will be grouped in five major tasks: calibration, pre-reduction, reduction, analysis and utilities.

Calibration Tools

These tasks work on flat field and calibration lamps exposures and create tables with calibration coefficients. Given the stability of the instrument, the package will provide library calibration tables which can be used as standard calibration for scientific exposures. Calibration tools have been designed to work with a high degree of automation. Many tests have been carried out on high resolution spectra from different instruments such as SARG@TNG, UVES@VLT, NIRSPEC@KECK, FEROS@ESO-MPI2.2M.

By providing a configuration file with the instrumental parameters such as the camera focal length, detector pixel size, gain and RON, the echelle groove density, the nominal echelle blaze angle, a pipeline can be run to quickly produce calibrated spectra and some quality check in a fully automatic mode.

Pre-reduction Tools

The aim of these tasks is to transform a science exposure into a FITS file with straightened orders ready for the final extraction of mono-dimensional spectra.
These tasks are carried out in fully automatic mode.

Reduction Tools

Analysis Tools

These tasks will work on extracted 1-D spectra and will provide some standard features such as continuum normalization, flux calibration, signal filtering, line profile analysis tools, spectra cross-correlation (to derive relative velocities between spectra), as well as a spectral line rest wavelength reference, suitable to allow a fast access to spectral features of interest, especially for the on-line data quality assessment.
The GUI will look like the popular DS9 display program: it will support multiple frame buffers, scaling and color-map manipulation, arbitrary zoom, pan and rotation, and obviously all the DrG tools to give the user the opportunity to check interactively each step in the reduction and analysis process.

Utilities Tools

Some other utilities will be provided, such as general purpose command-line FITS calculator to allow the user to easily do arithmetic computation of arbitrarily complexity among any wished number of FITS images, by also including computation of averages, weighted averages, medians etc.

Automatic Wavelength calibration

Wavelength calibration of echelle spectra usually demands to manually identify a few lines from a calibration lamp exposure on at least three orders well distributed along the echellogram. By using a suitable atlas of spectral lines it is possible to compute a starting guess for the dispersion relation and iteratively refine it by adding more and more lines to the fitting process. Then a global dispersion formula can be fitted to combine the whole set of orders (in this way it is possible to get a more robust fit where only a few lines are visible).

At present the astronomical community seems still lacking a general software able to perform a wavelength calibration of echelle spectra without predefined solutions or user interaction. This puts serious limits to the development of data reduction pipelines working in a completely unattended mode. With the GIANO DRS we have developed a program that uses a starting guess for the order dispersion model, accurate enough to achieve a good calibration without any user action. This is possible by making use of WCSLIB, a library developed by Mark Calabretta at the Australia Telescope National Facility (http://www.atnf.csiro.au/ mcalabre/index.html) to handle coordinate systems within FITS standards. Accordingly to the definitions in Greisen et al. (2006), we set:
p: Pixel coordinate (abscissa)
q: Intermediate pixel coordinate
q1: Corrected intermediate pixel coordinate
x: Intermediate world coordinate
s: World coordinate
where:
$q = p - CRPIX_m$
$q1 = c_0 + c_1 \times q + c_2 \times q^2 + c_3 \times q^3 + ....$
$x = q1 \times CDELT_m$
and $CRPIX_m$, $CDELT_m$ are the standard FITS keyword. Transformation from x to s (and back) is computed using spcx2s() and spcs2x() WCSLIB modules. These routines compute a suitable physical relation for the dispersers commonly used in astronomical spectrographs, in order to define a world coordinate function and derive spectral coordinates. The relation applies to the simple case of a single disperser and under the assumption that the radiation enters perpendicular to it. The requested physical parameters for such a transformation are the grating ruling density $\sigma$, the order number m, the angle of incidence $\beta$ and the $CRVAL_m$ ($\lambda$ value at reference point). For each order the following starting conditions are adopted:

\begin{displaymath}
q1 = q,
\end{displaymath} (1)


\begin{displaymath}
CRVAL_m = \frac{2.0 \times \sigma \times sin (\beta) \times cos (\gamma)}{m},
\end{displaymath} (2)


\begin{displaymath}
CDELT_m = \frac{cos (\beta) \times cos (\gamma)^2 \times \sigma \times pix\_size}{f_{cam} \times m},
\end{displaymath} (3)

where pix_size and $f_{cam}$ denote the detector pixel size and the camera focal length, respectively.
The 1-st relation comes from the expected blaze wavelength, the 2nd from the expected linear dispersion at the central wavelength.

At a first stage, for each order the task looks for the $CRPIX_m$ value which maximizes the number of matches between observed and library lines.
Linearity of $m \times CRVAL_m vs.  m$ and $m \times CDELT_m vs.  m$ relations is used to distinguish each time well fitted orders from bad ones. In the second stage, the $CRVAL_m vs.  m$ relation is finally fixed and the task proceeds to find $CRPIX_m$ values and c0,c1,...,cn polynomial coefficients order by order, progressively involving lines from the end of the orders, where deviations from linearity are more severe, and increasing the degree of polynomials. Much care has been put to avoid the incidence of false line matches as much as possible. Orders correctly modeled are used to derive a global dispersion relation which is suitable to derive an accurate dispersion relation for all missing orders.

As an example, the residuals of the wavelength calibrations for two different spectrographs, namely SARG and FEROS give $ rms \approx 0.2 \div 0.23 pixel$, corresponding to rms ≈ 0.009 ÷ 0.001  Å.

Image fig_giano_sw6
Left panels show the residual of the wavelength calibration for SARG@TNG echelle spectra in units of Å (upper panel) and pixel (lower panel): 2144 lines have been identified, finding $rms \approx 0.01$ Å  $\approx 0.23 pixel$. Right panels show the same quantities for the FEROS@ESO-MPI-2.2M echelle spectra: 7526 lines are identified with a resulting $rms \approx 0.009$ Å  $\approx 0.19 pixel$.