Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1556

News	FAQ
Search	Home

Subsections

• Programmability
• User Access to Data
• Documentation
• Portability
• Examples of VLBI Experiments

General Considerations

Programmability

Most of this document deals with required functionality of AIPS++ ``tasks''. However, the VLBI community is also very concerned about the programmability of the package. Traditionally, many VLBI astronomers have (necessarily) been involved in algorithm development. And it is clear that this is a continuing effort in all aspects and stages of VLBI processing. It is recognized that classic AIPS has imposed a high threshold for non-specialists to test and implement new methods.

In AIPS++ there are many layers of increasingly complex software. It is hoped that the user interface and script language (Glish) will provide a platform for simple data operations and straightforward processing. However, it seems unavoidable that at least some fraction of algorithm implementation by VLBI astronomers requires the use of compiled code. Because of the large datasets involved in VLBI processing, speed is a consideration for these projects. Easy access to class libraries, interfaces to C and FORTRAN, and documentation on the appropriate level seem to be required to ensure programmability. Skeleton tasks, tutorials and even training courses should be considered.

User Access to Data

There need to be flexible and simple ways for the users to manipulate their u,v datasets, for example:

• The user should be capable of using the host system's capabilities and utilities to manage hisher datasets. The datasets should use a normal file name, and the user should be able to use the host directory hierarchy to best organize the data.

• Tasks should generally take multiple input u,v datasets where this makes sense. For example, the map making program should be capable of taking multiple input datasets, all of which contribute to the output images with user defined weights.
• There needs to be a flexible way for the user to select the particular subset of data, in a dataset, to be processed. As well as selection based on time, antenna number, frequency, subarray, etc, it should be possible to select based on the values of other data (including monitor data).

• It should be possible to extract a subset of data from a dataset and manipulate it in some powerful command language. This would include displaying the data and optionally replacing it in the dataset (e.g. multiply the amplitudes for some antenna by an arbitrary factor).

• It should be possible to extract a subset of data from a dataset in a variety of formats (e.g. FITS or plain text) in order to transfer the data to other programs or packages. It should also be possible to read the modified data back into AIPS++ using the same formats.

• For applications where the built-in tasks and command language features are insufficient, there needs to be a program interface to allow the casual programmer reasonable access to the data. Some flexibility and efficiency can be sacrificed in making this interface comparatively simple. FORTRAN programmers should be supported.

Documentation

Another point we want to emphasize is one of documentation for non-specialist users. Our users often have no previous experience in synthesis imaging and start directly with VLBI. They need a cookbook-like introduction as well as tutorials.

Portability

For the VLBI user community it is of great importance that AIPS++ is portable to all systems that have significant support in the global VLBI community. At the moment these are mostly UNIX systems; besides Solaris and SunOS, especially DEC Alpha, HP/UX and Linux platforms are popular around the VLBI world.

Examples of VLBI Experiments

To get a feel for the possible data types that VLBI processing has to take into account, we list below possible VLBI observations for which AIPS++ processing andor application development should be possible.

The first part of this list concentrates on data types that we consider part of (future) standard VLBI practice:

• continuum observations in single or dual polarization

• spectral line observations in single or dual polarization
• observations in which polarization, frequency, andor pointing centre may be rapidly switching in time.
• simultaneous observations in multiple frequency bands (e.g. for observing multiple lines simultaneously or multi-frequency synthesis or S/X), with variable numbers of channels within each band

• pulsar-gated data
• mosaiced observations with severalmany pointing centres (e.g. large line sources, gravitational lenses). This must be supported at both the u,v dataset and image dataset level
• polarization data with unequal uv-sampling, where all four polarization parameters are not available simultaneously, as might occur for networks with inhomogeneous polarization sampling or time-switching of the recorded polarization
• combination of data from different observations that have different (but overlapping) spectral sampling
• time-series data of profiles and visibilities (e.g. pulsar data with bin number as a data axis)
• multi-array datasets (e.g. MERLIN+EVN)
• multiple correlations from multi-field centre observations, for which the calibration should be identical (e.g. gravitational lenses)

More specialized dataset types which could be taken into consideration in the design of AIPS++ are:

• space VLBI observations

• observations during which the source changes structure (e.g. SS433)

• cluster-cluster data (e.g. WSRT-VLA multi-antenna VLBI)

• burst sampling for mm-wavelength VLBI

• triple correlation (including the case where one of the visibilities has a different frequency)

• combinations of the above (e.g. pulsar gated data in cluster-cluster mode)

Figure 1: A possible model for data flow for VLBI data in AIPS++. The correlator specific format may contain all the calibration data. Examples of some of these are denoted in this figure by their classic AIPS table two letter codes: e.g. PC for phase cal data, SN for amplitude calibration for example based on state counts, TY for system temperatures, FG for flagging, MC for correlator model components. Standard reduction has a specific VLBI part which involves calibration based on external data and fringe fitting. This allows the Measurement Set to be averaged in frequency and time. Following this, standard imaging and (self)calibration techniques are available to improve the image quality and the model of the source and sky.