Real Time Software

The basic operation modes

The actual control of ALMA observations will be run by the ALMA operations staff. There will be basically four modes of operation, with increasing levels of automation:

1.

Through a technical interface, allow/deny technicians complete access to all the control points available on each device, for debugging and maintenance purposes. The system should include such a facility, under control of the operator, for determining whether the device is to be used for observing or is withdrawn for maintenance.

2.

Control the array in manual mode. This mode will allow direct control on the hard-real-time system and on the quasi-real-time system (see below). This will provide a way to test all the functionalities of the array, as well as to develop and debug new ways of observing.

3.

Start astronomical observations or array calibrations in the interactive mode. This will pass the actual control of observations to the interactive astronomer (guest or staff), through a graphical interface. This interface will allow control of the observing process, with automatic feedback from the data pipeline. The astronomer and/or the operator will have the possibilities to interrupt a sequence of events at any time, to modify the observing strategy, to switch to a different mode to perform needed but unforeseen calibrations, or to switch to the dynamically scheduled observing mode. While the manual mode is mainly intended for instrumental tests and procedure development, the interactive mode is aimed for observations using the standard modes, but requiring interactive observing (e.g. targets of opportunity for which a fast reaction time is essential).

4.

Pass control to the dynamic scheduler, which will select among its queue the observing project the most suitable for the current observing conditions, and run it in the most efficient way, using up-to-date environment parameters from both the real time system and the data pipeline. Though scheduled in a different way, the available observing modes will be the same as for interactive scheduling; in fact the astronomical parameters will have been input by the astronomer (PI/CoI), with the same graphical interface as above, but used long before the actual observing. Projects requesting to be scheduled at a precise time, like VLBI, or observation of comets, occultations, .. etc. will be included here but with a top priority in the required time window.

For ALMA we need the possibility of dividing the antennas in several sub-arrays: for instance, assigning some antennas to an interactive observer or to the dynamic scheduler, and others to operations staff for pointing model determination, baseline determination, or engineering tests. Sub-arrays will be operated simultaneously through different operation sessions, each sub-array being in any of the four above modes. he antennas will be allocated to those sessions by the operator with highest priority to maintenance and array calibration sessions, since they condition the general performance of the instrument. De-allocation of an antenna from an observing session may require some calibrations to be performed before the antenna is handled to highest priority operations. The allocation of antennas to sub-arrays/sessions will take into account the hardware constraints imposed by local oscillator control (up to 4 different simultaneous LO setups), and by the correlator (up to 16 different correlator sub-arrays).

In the next two subsections (2.2, 2.3 we describe the basic requirements on the manual mode of operation, and on the interactive mode. The requirements on the dynamic scheduler are detailed in a specific section (4).

   
Control Command Language

In this mode the astronomer will be given direct real-time control on the instrument (or part of it), either by typing simple commands, or more frequently by running pre-edited scripts. Because the real-time system cannot be worked upon without stopping observing, it is imperative that it be as reliable as possible, and sufficiently flexible to accommodate the inevitable evolution of observing modes as the instrument becomes better understood.

Entities to be controlled are:

• the hardware, controlled through what we call the hard-real-time software, exercising detailed control of the antennas, receivers, local oscillators, correlators, ... etc.; this include commands to initiate antenna motion to the source and tracking at the requested speed, and actual requests for integration being sent to correlators.

• the quasi-real-time software, or software that must be run only when observing conditions (including time) are known, e.g. to compute source coordinates in the antenna system, prepare LO and IF filter settings according to the requested frequency and Doppler tracking parameters, ...etc. but also to reset some observing parameters, such as integration times, collimation and focus corrections according to the atmospheric data or to data pipeline products;

• the data pipeline itself, to which basic data must be passed such as which data reduction software/procedure should be used, and some input parameters which are not present in the data header information, and which cannot be guessed from the data records themselves.

 

The key to flexibility in the observing system is that the constructs that it deals with must be as close to the elementary hardware capabilities of the instrument as possible. This must be balanced with the need that the input to this system must be sufficiently simple to be read by expert astronomers: they should be able to decide by just looking at a script whether it will cause the instrument to do what the programmer had expected, without wasting any telescope time.

For this reason we require that the commands should be expressed in a simple command language, for which keywords are as much as possible words in a commonly understood language (we may agree on English). The number of single-character control operators must be strictly minimal.

Desirable features in the language built-in functionalities include:

• non-ambiguous abbreviation of keywords should be accepted

• macros for abbreviation of frequently typed sequences

• procedures to which parameters may be passed

• definition of variables and arrays, with numeric or character content

• evaluation of expressions, including built-in functions

• conditional execution facilities

• loops

• error recovery facilities

• interruption facility in procedure execution

Several scripting languages with these functionalities are actually being used at various observatories. The actual choice will mostly be based on software design considerations.

Foreseen use of variables/built-in functions is the ability to react on environment data such as meteorological data, phase monitor data, sidereal time, hour angle, source elevation, but also on pipeline output such as pointing collimations, detected calibrator flux, noise, flux and snr in the output map, ...

The exact balance of functions between observer's interface, quasi-real-time system, real-time system, and data processing pipeline is in the end likely to be dictated by constraints first seen in the detailed design of the software systems. However, it is a useful planning tool to have a first guess at the capabilities of the real-time system available, not only for designing the real-time system but also for designing the preceding tools and the archive data formats. We provide this first guess in an Appendix (A), in the form of a scripting language which might control the array. Note that this language is not really intended for direct use by astronomers, nor does it provide functions necessary for the array operators to control the observing. However, as an interface in the middle of what might otherwise be regarded as a very large black box, it is hoped that it can provide a planning tool for some of the other critical elements of the software system.

A few of the more difficult decisions for this scripting language/interface may be briefly noted:

• First, the baseline design for the ALMA local oscillator system requires fairly sophisticated choices to be made about the lock points for first and second local oscillators. The implication is that, although one can make a continuum observing file that can be given to the real-time system at any time, any useful spectral line file must be prepared for a specific date. This implies that the final LO/correlator setup can only be made at the actual time when an observing session is started. Advance warnings will have been given to the observer when running the Observing Tool, with predicted ranges for the LOs, and eventual restrictions. Second, the flexibility of the correlator hardware will be somewhat restricted because utilizing the full flexibility of the correlator would be technically difficult, and lead to more complication in the real-time system than desirable. Thus, we recommend that options to support different bandwidths or spectral windowing in the two halves of a baseband pair (usually used for opposite polarizations at the same frequency) be given a low priority.

• The suggested interface puts into the real-time system precession for J2000 to date. It is suggested that all reasonable corrections be put into the real-time system so that milliarcsecond level astrometry can be done differentially. It should include, eg, the latest IAU nutation, earth tides, general relativistic corrections and diurnal aberration. Interpolation of positions for solar system bodies would be supported, along with the phase correction for the first order parallax. Proper motion calculation for galactic objects should also be taken into account.

• Although most observing control will be done through the observer's tool, a couple of non-elementary concepts are supported by the proposed interface, in order to make the input scripts more readable for software debugging purposes by reducing the occurrence of repetitive text. These are first, macros, so that long descriptions of setups need not be repeated, and second, loops.

• Operating a subset of antennas as a sub-array for calibration etc., as mentioned above is a clear necessity. It also seems useful to us to provide provide also sub-arraying inside an observing project, permitting an observer to divide the antennas allocated to him into independent groups. Perhaps the most common use would be to detach three or four antennas to do tipping curves to evaluate the atmosphere, while the main body continues to make astronomical observations. In that case, if those antennas have to be handled in a different observing session, proper software connections should allow the results to be tested in the main session.

   
Graphical User Interface

The Graphical User Interface (GUI) is now the de facto standard in the commercial world. It is proposed that all interaction with the ALMA system will be through GUIs, except for the low level scripting that controls the real-time system.

Because GUIs are a fundamental part of the presentation of the instrument, they should be implemented with a common style and reusable components. Many interfaces will be required to the instrument and its data flow for different purposes. Administrative access occurs in the scheduling phase, engineering access during operations, and scientific access during an archive search. This implies that a variety of people using different computing platforms from different locations will access the instrument. As much as possible, the GUIs should support multiple platforms and remote access. All GUIs should have an embedded standardized help system so that documentation is always available.

Support for observing commands and sequences will be handled with an Observing Tool that must be able to produce either scripts or object sequences for the real-time engine, both outputs resulting in the same observations when executed. Integration with source catalogs, image databases, and spectral line catalogs are essential to create a high level tool. The Observing Tool can be used by an astronomer to prepare an observing script, or by the telescope operator to produce an updated script for a project.

The correlator complexity presents particular problems that require a GUI for most non-trivial setups. The Correlator Configuration Tool can be run stand-alone or be invoked by the Observation Tool.

A list of some of the major GUIs can serve as a model for interaction with the data flow. Details of some of these interfaces are found in other sections.

• Preparation of observations:

  • Proposal preparation tool

  • Archive search tool (historical project search)

  • Observation simulator

  • Observation tool

  • Correlator configuration tool
• Real time control and monitoring
  • Operator array control

  • Data cube viewer

  • Monitoring
    • Antenna based UV data
    • Live tables
    • Multi-variable plots versus time
    • Scatter plots
  • Engineering device control

  • Project status visualization tool
  • Data cube viewer

• Archive data extraction interface

   
Observing Modes

In this section we describe the observing modes of the instrument. This list cannot, by nature, be made definitive. Among our requirements is the fact that these modes can be tuned, and new modes be developed, without involving deep changes in the system: i.e. by editing scripts in the real time control language. When fully checked, these modes will be available through GUI interfaces to the general user.

List of observing modes

All these modes involve a sub-array. Any number of sub-arrays, working simultaneously on any different modes, different projects (and different observing frequencies) are possible.

Interferometric

Single Field Classical mode for interferometers. Alternate between on-source cross-correlation scans and phase calibration scans. Switching can be quite fast if needed, to follow atmospheric phase variations.

Multi Field Mosaics Same as above, but on-source cross-correlation scans are taken at nearby, pre-defined positions in the sky. Alternate between on-source and phase calibration scans.

On-The-Fly Mosaics The on-source cross-correlations are taken while the antennas drift on the sky along a pre-defined pattern. Every so many scans, phase calibration scans are done.

Phased Array

Normally used for VLBI. On-calibrator cross-correlation scans are needed to calibrate the phases. Flexible control over which antennas are used for the phased array must be provided, to optionally eliminate antennas which are deeply shadowed, or which have other problems.

Total Power

On the Fly Mapping The on-source auto-correlations or total power readings are taken while the antennas are driven across the sky in a pre-defined pattern. Every so many scans, a reference auto correlation on blank sky may be needed.

Position Switched Mapping Mainly on-source auto-correlation scans. Every so many scans, a reference auto correlation on blank sky (off-scan) is needed. The optimal integration time on off source scans depends on the number of on-source positions and the integration spent time on each one. Occasional amplitude calibrations (auto-correlations on hot and cold loads).

Frequency Switched Mapping On-source auto-correlation scans. The frequency is switched to a slightly different value to obtain the reference scan. Useful if no clean reference field can be found, or if the receivers/atmosphere stability does not allow for the antennas to be switched to a different position. This mode can be combined with on-the-fly mapping.

Special observations

Some observing modes will need mode detailed studies:

Pulsar observations

Solar flare tracking.

Project Calibrations

We first give calibration modes that may have to be done for a given project. Some will be done once when the project is started or ended; some will be done at regular intervals during a session. This interval will appear as a parameter in the description of observing.

Amplitude calibration Needed for all astronomical observations: Short auto-correlations on blank sky, hot and cold loads. Used to measure system temperatures at the observing frequency. Blank sky to be done as often as needed to follow variations in atmospheric transparency; loads need to be done only if receiver performance varies. One may need to store the results for the source and the phase calibrator separately (for fast switching phase calibration).

Gain Calibration

Phase Independent phase calibration is needed for most interferometric and phased array observations. Can be done frequently if needed, to correct for atmospheric phase fluctuations. One observes a point source (phase calibrator), near the project source. Some projects may need several different calibrators. The observation may be done at the observing frequency or at a different (low) frequency band.

Amplitude In many cases the phase calibrator is strong enough to be useful to calibrate the gain amplitudes. In that case its flux has to be referred to primary flux calibrators (see `flux calibration' below).

Bandpass calibration Needed for most interferometric observations. One observes a strong point source (calibrator), in the observable sky. The integration time will vary according to the project needs. The same calibrator must be observed both at the observing frequency and at the frequency band used for phase calibrations.

Pointing/Focus calibration Needed for most astronomical observations. Done by cross-correlation scans, either on-the-fly or five-point scans on pointing calibrator, at low frequency, every 10-30 min. Extrapolated pointing parameters from last few pointing calibrations need to be fed back into antenna control. One may also be able to self-calibrate the pointing/focus from the observed source itself, if it is strong enough. At the low frequencies, pointing/focus calibrations may not be necessary.

Flux calibration Used to set up the absolute flux scale, by observing a source of predictable continuum flux (could be in total power or interferometric mode).

Polarization calibration This can probably be derived from phase calibration observations.

Array Calibration

We list here observing modes that are used, at time intervals, to calibrate the array itself. The results are useful to all projects.

Pointing calibration session A set of pointing calibrations on several pointing calibrators all across the sky. Needs to be done only after some antennas have been moved. Has to be checked periodically. Occasionally one should measure the relative pointing of the different frequency receivers, by using either a strong planet in total power mode or a strong quasar in interferometric mode.

Baseline calibration session Done by cross-correlation scans on several calibrators all across the sky. Needs to be done only after some antennas have been moved (but some antennas which have not been moved have to be included in the sub-array). One may observe for some time with antennas the positions of which have not been precisely measured, provided that these positions are known for the final reduction.

Delays calibration Needed for most interferometric observations. One observes a strong point source (calibrator), in the observable sky, for a very short time to measure the relative delays to the antennas.

Beam shape calibration Holography measurements on cosmic source, to monitor beam shape and focusing of antennas as a function of elevation.

Sample astronomer input for an observing mode: Single-field Interferometric mapping

Section: Field_info
   Name:      IRAS 15194-5115
   System:    EQUATORIAL J2000
   Longitude:  15h 19m 21.90s
   Latitude:  -51d 15' 19.0''
   Beam_size: 0.2''
   Field:     60''
   Map_Cell:  0.03 x 0.03''   
   Map_Size:  2048 x 2048 
   Weighting: Natural
   Taper:     None

Section: Spectral_info 
   N_Bands: 4 
   Names:        HCNv0     HCNv1     HCNv2      Continuum
   Frequencies:  xxx GHz   yyy GHz   zzz GHz    350.000 GHz 
   Velocities:   -15       -15       -15        0 
   Velocity_ref: LSR       LSR       LSR        OBS 
   Widths:       100 km/s  100 km/s  100 km/s   1 GHz 
   Resolutions:  0.1 km/s  0.1 km/s  0.1 km/s   5 MHz

Section: Calibration
   Phase_calibrator:              closest  &&  flux > 0.1Jy
   Phase_calibrator_frequency:    90 GHz
   Phase_calibrator_rms:          10 degrees
   Phase_correction:              yes
   Bandpass_calibrator:           best
   Bandpass_phase_rms:            2 degrees

Comments:

On these inputs the observing tool should react, e.g. :

• Estimate the size of the array configuration, giving some beam information (ellipticity, sidelobe level)

• Compute first LO and second LO frequencies, converting bandwidths and resolutions, if provided in velocity units, into available correlator modes,

• Estimate output data rate

• Give all sorts of warnings, like the following:

  OK, with the available setups, you will get resolutions of 0.06, 0.06,
  0.06 km/s, 8 MHz, rejection of objects in the skirts of the beam by
  about 28 db, an integration time smearing in the outer parts of your
  map corresponding to a 6\% loss of peak flux for a point source, and a
  data output rate of 37 Gbytes per hour.
  
  128MHz bandwidths will be used, but the upper 5MHz and lower 8MHz will
  not be available all year round to allow for Doppler tracking, ...