Holography Software Development for the MMA
This document has been prepared for the MMA Holography PDR to take place in Tucson on 1999-Apr-19. It should be read in conjunction with the holography software requirements as described in the MMA Project Book and distributed for the meeting, and the draft note "Holography Support in AIPS++ DRAFT V1.0" by A. Kemball. This note considers only that software required to implement "single dish" holography. Discussions of interferometric holography are deferred to a later time.
In brief, there are three major software subsystems required to implement holography for the MMA.
The above must work in a nearly-automatic pipeline system, and must be amenable to modification by operations and other staff as the holography techniques required for the MMA antennae are further refined.
If possible, it would clearly be of value to test the hardware and software systems together in advance of delivery of the prototype antenna, for example on the NRAO 12m telescope.
The detailed implementation strategy for the real-time systems is not yet decided – for example, which software to write, which to adopt. This section contains some general considerations for the real-time software as required for holography. Some preliminary use cases are shown in a later section.
In general, the requirements for single dish holography are similar to those required for on the fly mapping. The antenna rapidly scans (0.5deg/s) the beacon in azimuth and elevation. If a satellite is used, the grid will have to follow the satellite motions. Note that for a terrestrial beacon the refraction calculations required for observations of extra-atmospheric objects will need to be turned off.
At 90GHz the scan length will be about 5 degrees, and the row separation about 1 arcmin. This implies that the entire raster will require about an hour of observing time. During the raster frequent reobservations at the boresight position are required for calibration purposes. The MMA antenna specifications imply that each boresight sample will only cost a few seconds of move time, so they can be taken very frequently if desired. Similarly, occasional pointing calibrations will also be required.
During the raster and boresight observations data from the holography backend need to be taken. Samples from the holography backend will be required at a TBD rate, not faster than every 10ms. The real-time system shall be responsible for time-tagging the data.
The data samples will consist of complex (or possibly amplitude, phase) values. It is presently undecided whether or not the samples will be single complex values, or spectra. If the latter the spectra will consist of no more than one hundred points.
Assuming 2x4 (8) byte complex samples (less should suffice), the worst case data-rate from the holography backend will be 640kb/s (100 point spectra, 10ms sampling). The "best" case rate is 0.64kb/s (1 point, 100ms). The former is uncomfortably close to the achievable upper limit of CAN – a fast commercial fieldbus under consideration for the M&C bus (Brooks, private communication). Thus at the higher data-rates an additional communications path may be required, at the lower data-rates the M&C system would suffice.
In either event, as the data is collected coordinate information will have to be associated with the samples. This will be done by interpolating the encoder readings (effectively sampled at 40Hz according to the antenna RFP) to the sample time and applying the pointing model resulting in sky azimuth and elevation.
The data must be written into a data format suitable for data processing and analysis. There is no standard for recording holographic data in FITS; however the GBT project will (has?) define a FITS format which might be suitable for MMA single dish holography. Another possibility would be to directly write the AIPS++ MeasurementSet format. This latter would have the advantage of removing a stage in the reduction pipeline, reducing the latency of the processing. On the other hand, FITS is more suitable for archiving. On balance if the GBT FITS format is suitable it should probably be adopted.
Interactive displays should be provided for the benefit of operators and other interested staff – for example a picture showing the fraction of the raster which has been observed and the estimated time to completion.
The AIPS++ project has assumed responsibility for holography data analysis. Interferometric holography within AIPS++ has already been implemented for the WSRT as part of their new Telescope Management System (TMS). Single dish holography will be implemented within AIPS++ by AIPS++ and GBT staff in 1999.
A principal difference between MMA single dish holography and other holography requirements of AIPS++ is the use of a terrestrial beacon in the near field of the antenna. The AIPS++ staff is familiar with the literature in this area and appreciates that it is required for the MMA.
It is important that it be straightforward to make changes to the analysis software in a to allow for unanticipated calibrations and to perform ad-hoc operations on the data. Much of this analysis will be written as Glish scripts which has powerful scripting and data processing features.
Similarly it is important that various tools for plotting and viewing the data in all stages of its reduction be available. The general AIPS++ toolkit should suffice in this regard.
The fundamental outputs of the analysis stage are an image of surface residuals, and the important values determined during the analysis such as the pointing offset.
The output of the data analysis stage is an image of surface residuals in an antenna coordinate system. This needs to be turned into "instructions" for adjustment of the surface of the dish. The following discussion outlines a procedure similar to that used at BIMA (Lugten, private communication).
A model is fit for each panel on the dish. For example, at BIMA they fit a combination of a vertical offset, a tilt, and a twist. Pixels are given a weight to accommodate pixels that fall on more than one panel. This fit can then be turned directly into screw adjustments for the panel, and a report of all these adjustments represents the instructions necessary to adjust the surface.
Clearly it will be important to determine what model should be fit for the panel errors. It must be straightforward to change this model. For example, we might start with a vertical offset only, and add more terms as the surface comes closer to its final configuration.
Besides a textual list of adjustments, it is desirable to produce a visual map showing the panels, surface contours, and the required turns for each screw.
A nearly automatic pipeline for implementing holography observing, data analysis, and surface adjustment instructions shall be implemented by MMA staff. Given the central role of AIPS++ in this pipeline, the pipeline will almost certainly be implemented in Glish.
Note that such pipelines have previously been implemented in interactive observing systems, perhaps most notably for the Parkes Multibeam survey, as described in:http://www.stsci.edu/stsci/meetings/adassVII/barnesd1.html
Use cases are a method of describing and enumerating software requirements. The following use cases are preliminary, with known flaws - nevertheless comments are solicited.
Use Case: Perform Holography Observation
Description: Move the antenna in a raster scan pattern centered on the source without stopping. Simultaneously collect time-stamped and position-stamped amplitude and phase data. At the end of a scan row be able to stop the observing and perform system calibrations. Be able to start an observation beginning at any scan row.
Use Case: Collect Holography Data
Description: Collect amplitude and phase data to include a time and position stamp. Once setup, the collection can be started and stopped at arbitrary times.
MAIN SUCCESS SCENARIO
OPEN ISSUES (optional)